Project plan Archives - TAB Corporate

Monitoring: The Plan

Project Management for Small Business XIII

Thus far in this series, we’ve concentrated on making a project plan. The planning process is where the project manager can have the greatest impact. A well-planned project is much more likely to succeed than a poorly planned project. Once s project is properly planned, the project team will turn their attention to executing the project. The project manager’s responsibility changes to monitoring the project.

Much of what we’ve covered thus far for small business projects had to do with creating a manageable plan. If your plan is too complex then it will be of no use during the execution. The project team just starts working, and there are not really any good controls to determine how the team is doing against the plan. Therefore, a manageable plan is one that is primarily used as a tool to track the project execution, and to determine how well the project is proceeding against the plan.

Monitoring involves tracking the execution of the project to assess how well the project is proceeding with respect to scope, schedule, and budget. It also involves monitoring issues and risks. Here are the things that the project manager should look out for on a small business project, and some best practice suggestions.

Scope                                                

Is the project going to meet the full scope outlined in the scope document? The best way to review scope is through regular client reviews. The well-known Agile Methodology is designed to confirm scope throughout the project. Traditionally, projects would complete all activities before the client was able to start reviewing the results. If there was a larger mismatch between what the client expected and what was delivered, the mismatch would be discovered when it is almost too late.

With Agile, the client is involved as a part of the project team. The team frequently completes small deliverables that the client can review. This is intended to achieve alignment between individual expectations of scope and what is delivered. The best practice is to involve the client intimately throughout.

Change Management

A lot of project managers have the philosophy that changes are bad. Changes are not bad, and should be embraced. You may have high expectations that the scope document reflects the perfect outcome, and any deviation from the scope document is a bad thing. It’s important to realize that customers might do their best to include everything in the original scope, but sometimes they miss things. Moreover, businesses change and dynamic businesses try to take advantage of opportunities. Change is good for a project – as long as change is properly managed.

When it comes to change, the best practice technique is to only accept changes once an impact analysis has been completed. Each change needs to be evaluated in terms of impact to project schedule and budget. As long as the stakeholders are aware of the impact of a change, especially a significant one, they will be able to make an informed decision of whether to accept or not to accept changes.

Keep this in mind: while I advocate that change is good and indeed is necessary for a moderate-sized project to be successful, excessive change will doom a project. If the client is changing their mind constantly or just didn’t think through the scope very well at the beginning, the project will fail. In this case, it’s better to pull the project early instead of proceeding toward a disaster.

Schedule & Budget

Schedule and budget monitoring are the most mundane areas of project management. But they are also very important. My advice is to be sure to review the schedule and the budget weekly against the actual accomplishments and expenses of the project team. I have often seen project managers for small projects forget the schedule and budget as soon as they are created. Your schedule and your budget are not just planning tools; they are monitoring tools that will help the project manager keep costs and time from getting away from them. There is nothing worse for a project manager than having to answer to the owner about why they are late or over budget; or worse, that they don’t really know if they are within scheduled and budget.

One thing to consider with schedule monitoring is percentage complete. How often have you seen a project task proceed along just fine from 0% to 95% complete – and then just stays at 95% until it is done? This happens all the same, especially with technology projects. Here are two techniques that you can use to prevent these tasks from blowing the schedule:

  • Make sure to track original due date & currently forecasted due date for tasks.
  • Also, make sure to track the last percentage complete & the current percentage complete for tasks.

If you don’t track at this level of detail, you can lose track of the fact that the project is slipping. Zero in on any tasks where the forecasted due date is changed and the percentage complete is not changing. These are the tasks that will kill a project. Monitor these tasks closely every single day.

Issues

Issue review should be a standard part of your weekly project status meeting. The whole status meeting could be spent discussing issues. Therefore, prioritize your issues and allocate a specific amount of time to review them. Start with the highest priority issues and work your way down. If you discuss an issue at two consecutive meetings and cannot resolve it, escalate it to the project stakeholder. Once the issue is resolved be sure it is documented both to the whole team and in the project issue register.

Risks

Hopefully you’ve developed good mitigation plans to risks during the planning process and have a small list of risks on your radar as the project is proceeding. Similar to issues, review project risks with the team. They don’t need to be reviewed at every status meeting but should be on the agenda periodically. The review of risks would simply be to discuss whether anything has changed that either makes the risk obsolete or exacerbates the likelihood that it will hurt the project. If a risk has gotten more likely, make sure that the stakeholders are aware of this. Also, assemble a SWOT team of the people most likely to be able to resolve the risk. Again, don’t just assume risks will go away; risks are real and if not addressed head on, can ruin an otherwise great project.

In future posts, we’ll drill down into monitoring the health of the team, monitoring success criteria and then discuss ultimately whether the project is really successful.

 

 

Project Plan Assumptions

Project Management for Small Business XI

Because the project manager wants to get on with a project, the last two sections of a project plan tend to be the risks and the assumptions. These sections are often started from a previous project plan, and adjusted for the current project. It’s my experience that in a small business project plan, very little thought is given to risks and assumptions.

Undistributed middle argument map

All about assumptions. (Photo credit: Wikipedia)

If you’re an experienced manager, you’ve definitely run into the following scenario numerous times:

Customer: My team has started to review the new system. We couldn’t find the yield management module. What is the status of it?

Project Manager: Yield management is out of scope.

Customer: You’ve got to be kidding! The system is useless to me without yield management.

Project Manager: But, it wasn’t in the requirements and you approved the requirements. Iassumed that you knew it was out of scope.

Customer: Yes, but I assumed yield management was included. It’s so important to our business.

In this scenario, the project manager may indeed be in the right.  But this is a situation where being correct is not much of a consolation.  Here, everyone has lost.  In small business projects, important assumptions need to be stated, and be to very clear.

Project assumptions consist of external project dependencies as well as scope related clarifications. Regarding scope, you can include the important out of scope items either in your Project Scope section or in the Assumptions section.  The location doesn’t really matter, as long as your assumptions are clearly stated in the project plan. A cautious project manager may not want to call attention to assumptions; for fear that the project will not go forward. But hiding assumptions is a mistake, not being forthright will often land you in the scenario described above.

For the assumptions section of your project plan, try to put yourself in the shoes of your customer. What things might they expect that are not included? Make sure to write down these expectations. I would also recommend assembling the project team, just like for developing the risks, and going through an exercise of developing assumptions. This will not take a lot of anyone’s time, and will ultimately achieve a better result.

Here are some questions to ask when you develop assumptions for a project plan:

  • What items might my customer assume are in scope, and which items are out of scope?
  • How much time is required from each team member? Time estimates should include quality assurance, training and for support.
  • How hands on do I expect the customer to be? How much time will be devoted to customer support?
  • What external vendors are required? What additional funding will be needed for vendors?
  • What is our internal budget availability?
  • Are there technology dependencies that involve assumptions? For example, is a new release of underlying software needed that includes a new feature?
  • Once the project is implemented, how much effort is required for support? Who will do provide the necessary support?

Finally, Occam’s Razor is a good principal to follow in developing assumptions. Generally, Occam’s razor advises that the right solution is often the simplest. More formally, the principle states that one should not make more assumptions than the minimum needed. That is, make sure that the important assumptions are stated clearly, and are not buried in a bunch of unimportant assumptions.  Small business project managers will do well if they keep Occam’s Razor in mind.