– See All Project Management Key Concepts –

The Final Report

What is the final report? It is a report that provides a summary of the project performance and how it went, either during that phase or during the entire project itself. As with all things in project management it can be a small piece of work or it could be a large detailed document in itself. It could be formal or it could be informal. It could range from a document just a few lines in your project measurement plan, or it could be the outputs of a retrospective if you’re delivering a feature using agile for example.

A retrospective occurs for us to say what went well, what didn’t go well, what still puzzles me and what have I learned. Asking those questions and feeding that back into the process and that could be documented as a final report for that iteration or that particular feature.

There are many different ways to use the final report. It can include things like the scope objectives – were they met? And evidence of them being met. Has the scope been verified, and has it been delivered and accepted by the stakeholders? The quality objectives, actual milestone delivery dates (when did we deliver these things) and any variances in those. Did we say we’re going to deliver here but we actually only delivered there? What were the variances, and why.

This also feeds into our lessons learned register. Lessons learned from the project will really help future projects if this information is available.

We’ve got cost objectives – the actual versus predicted cost, reasons for any variances, same with the schedule and same with any risks. Did we encounter risks? How did we resolve them? All of that can go in the final report.

The final report puts it in a nice sort of nice package for the end of project report. Part of this could also include a handover document to whoever you’re handing over to or ultimately delivering this project to. All that information that they might need down the track, who to go to for this system access, who to go to if they need to get more of this resource once it’s gone into BAU. That can be part of a handover and can potentially go into the final report as well.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

The configuration management plan

What is the configuration management plan? It’s a plan that defines those items that are configurable. In other words the items that require a formal change control – usually items that have been baselined, they have been locked into a point in time.

These things might be to do with your scope, your schedule, your cost, usually locked in at a point in time beause we don’t really want those to change without any formal process.

We don’t want them to change on an ad-hoc basis because obviously these will affect and impact the outcome of your project. If we’re changing the scope or the schedule or the timeline or the cost involved, those documents are usually baselined and then they require that formal change control process, and the process for controlling changes to these items.

So while it usually relates to these baselined items such as the project budget for example in our cost baseline, schedule, scope statement and work breakdown structure where we’ve broken down the scope statement into smaller activities for us to complete in order to to deliver those features or those pieces of scope.

In order to change this we’ll need to go through the configuration management process.

Like all plans in your project management plan it can be small, just a few lines of text or it can be large and detailed. It could be an entire document of its own design, depending on the size of the project, depending on the enterprise environmental factors (EEFs) of your organization. The main point is to outline which of those documents will need formal change control, and that can be completely up to you and the project sponsor. You can work together and advise which things need to go through a formal process to change. Anyone can raise a change request, and in your change management plan you note the change process, such as where that change request will go into once it’s raised. Once that change is approved after going through the approval process, we will need to realign the project scope or schedule to suit these new changes. Maybe more money or funding comes in, so you’ll have all of these steps and these steps will need to be outlined, and that’s why we have the configuration management plan.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

The Issue Log

What is the issue log? Throughout the life cycle of a project, you (as the project manager) will normally face problems or gaps, inconsistencies or even conflicts in a project. This stuff happens all the time, because your project is designed to bring about change, and so there will always be little things happening – stakeholders to manage or things people will be unhappy about. Maybe the scope needs to change, all of these little things are happening all the time in a project and they occur unexpectedly, and they require some action to bring everything back on track so that it doesn’t impact the project performance in general.

That’s when we need to raise an Issue, once these things have happened.

The issue log is a project document where all of these issues are recorded and tracked. It’s important to note that an issue and a risk are not the same. Before something happens, it’s noted as a risk, and we can note that in the risk assessment, and we’ll assign things like controls to that risk so that we can prevent the risks from happening. We’ll assign owners of those risks to look at the activities around those controls, make sure that things remain on track. Obviously not everything always goes to plan and we can’t always think of everything that will happen, so if something does happen it becomes an issue.

An issue should be noted in the issue log at that time. The issue log will help the project manager effectively track and manage those issues. We’re going to be assigning extra information to these issues so that we can effectively track those issues, and we’re ensuring that they’re investigated and resolved and closed.

Issues may happen at any time, and the issue log is updated as a result of the monitoring and controlling activities throughout the project’s life-cycle. As part of controlling issues it may result in a change request as well. If we’ve raised an issue and it’s resolved, but it is something that needs to change like the scope or the schedule, then we need to raise a change request. Maybe we’re changing one of those baselined documents, around our scope, our time or schedule, or our cost.

These are the three most most important things that will be baselined, and that might need to go through the formal change control process by raising a change request. Then you can update the issue log with all of the appropriate information once that’s resolved.

The data that we’ll put on our issues are things like the issue type, who raised that issue, the description of the issue, priority (is it high, is it low) who is assigned to the issue to manage it ongoing, the target resolution date (is in June, July or August etc), the status current status and of course the final solution to resolving that issue, which is where that change management or the change request might come into it if something needs to change.

So overall it’s a very important part of your project, because you will need to raise and manage these issues as they occur. You’ll still need to keep an eye out for risks as there are you know on the horizon as well before they turn into issues all of this is part of managing a project and keeping it on track and that is the Issue Log.

– David McLachlan

– See All Project Management Key Concepts –