5 Key Components of Project Delivery

Project Execution and Delivery

Weekly priorities and goals need to be set from the beginning. Set out a culture of delivery and accountability from the very start. On large projects – some team members can coast their way through the first few weeks of a project and before you know it – you are behind schedule. The success of a project is the result of the success of the day, week month and year of the project. Get the team members into the habit if self-accountability – i.e. where they tell the Project Manager what they will deliver today or this week and how this will contribute to the success of the project. This is where team selection is key – ensure that there are no passengers on the project team. People who are not contributing will suck the life and enthusiasm out of the project team and make the project harder to manage.

Utilize Project Team meetings a means of:

Communicating Status
Reviewing Performance
Making Plans for the coming week
Discussing risks and issues

This type of meeting should be held on at least a weekly basis depending on the level of activity and customer expectation. Rotate the chair, keep accurate list if minutes and follow up on actions regularly

Another function of this meeting is to gather information required for project governance to a site leadership or above site team. These updates are typically summary of the weekly project meetings. These meetings are also a means of highlighting issues and or requesting guidance and support at difference stages of the project.

At each major point in the project, e.g. after every big deliverable or milestone is complete – conduct a brief, honest review of performance, a lessons learned session to take forward any learnings into the next stage of the project.

Project Reports and Communication

Different organizations and industries will have their own requirements on the level and type of reporting and communication. There may be different templates to be managed depending on the level of reporting required. It can be useful here to only maintain a single reporting template for each project. The reporting template for each project should not become the focus of the work but should be used as a means for communication. On a project with a long duration, this can take a while to get right as the audience may vary and their weekly focus can shift from cost to schedule to risk to resources at a minute’s notice. The only recommendation here is to be honest, clear and transparent – the earlier an issue is highlighted, the earlier a resolution or support can be sought. Communication should always come from the Project Manager – and the PM should assign a delegate in the vent of absence. Stick to a consistent form of communication.

Project Issues and Resolutions

Throughout the course of any project -issues will occur. They can be technical, logistical, resource, risk, budget or schedule related. Instead of worrying about unknown unknowns – focus on what the strategy is for issue resolution. An example of this is:

1. Problem Statement
2. Probable causes
3. Impact to the Project – cost, schedule, risk
4. Conclusion or Root Cause – Where appropriate
5. Proposed Solutions
6. Recommendations
7. Support or Direction Required from Site Leadership or Above Site Teams via governance

Having a structure will help frame every problem and get the team into the habit of managing problems effectively.

Regular, honest and transparent monitoring of key performance indicators such as schedule, budget and scope will enable you to capture a potential issue before it becomes a bigger challenge to manage.

Managing Project Scope and Delivery

This is probably the biggest challenge facing project – the control of scope. The scope is agreed at the outset of the project via the Project Charter and other associated contractual documents. The detailed plan assembled before project kick off helps to clarify the definition of the scope further. With the best will and intentions – this scope will be misinterpreted somewhere along the way. Expect a dispute on one of the finer points of detail – this typically occurs when interfacing with a different system or having to manage another vendor or third party. In order to reduce the occurrence of such challenges always build risk around system interfaces and third party deliverables.

Another area where scope can increase or begin to creep is during “Corridor” or “Watercooler” conversations. i.e. someone may mention that – “It would be very useful to have a report on this new system that showed Purified Water usage on a Daily, Weekly and Monthly basis.” The statement may be true – but if is not in the original scope – it is not in scope. To some end users – statements made during conversations are a contract, an agreement by the project delivery person to include this requirement in scope and deliver it with the original scope of work.

Many organizations have procedures for Project Change Controls and managing extras. This may indeed be a legitimate business need but the original project costing and plan – it is not in scope. In order to include this requirement in scope the following must happen:

1. The end User or Client – Completes a project change request
2. This is assessed by the technical SME
3. An Impact report is produced in terms of Time, Cost, Risk
4. The end user accepts this proposal
5. The change in scope is approved at the Project Governance forum
6. The new requirement is included in scope and the original contract is amended accordingly.

Different organizations will have variations of this process but essentially the process must be respected.
There may be more simplistic examples were for the sake of good customer relations or lack of clarity in interpretation of requirements – a decision is made to absorb a change request into the original scope of the project particularly where the cost and time involved is negligible and will not impact the original delivery budget or schedule.

As a default position – it is always best to utilise the process that is in place as a starting point.

Project Closure

A common oversight in industry today is the effective and complete handover of a system and closure of a project so that all legal, financial and logistical obligations are discharged and recorded correctly to enable a project to close completely.

Before closure it is wise to conduct a review of project delivery against actual performance and original intentions. This can include the learnings carried forward from earlier stages. It is also important to acknowledge any challenges experienced and that you have implemented measures to ensure that a recurrence of the same issues is greatly reduced or eliminated. Items covered should be –

What worked well?
What needs improvement?
What should we start doing?
What should we stop doing?

If you happen to do business with the same customer or end user again – theresulting report is always a useful starting point.

Other items to be considered at project closure:

1. Any warranty obligations are have been honoured
2. A support agreement for operational support has been set up
3. All items within the project scope have been delivered
a. Documents
b. Procedures
c. Test Results
d. Training Evidence
e. Software Versions
4. All contractual obligations on both sides have been agreed and closed off

Project closure generally takes some time but this can be formalized with a meeting between all stakeholders to gain official agreement and consensus that the Project is now closed.

Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: info@systeme.ie with some background on your particular issue and we’ll be in touch.

Download our project rescue guide here Project Rescue Guide