Stop the Creep – or at least contain it!

All projects change – may be not quite a truism but close enough!  Life happens and it WILL have an effect on your project.

Upfront planning can help develop contingency planning and well as conducting an FMEA (Failure Modes Effects Analysis) to anticipate some events (i.e. Customs officers holding up equipment at the border).  Mother Nature though has been known to be unpredictable, delaying shipments, changing costs and even damaging equipment.  Imagine those companies in flooded Queensland, Australia who have literally seen their plants go down the river!

Once a project has been initiated, a huge challenge for any project team is sticking to the original scope.  While the previous examples have been more of an emergency, once the projects begins, many more people become involved and start wanting things added or changed.  These changes to the project are termed “scope creep”.

During the planning phase, a stakeholder analysis can help identify those people who may want to see a slightly different outcome or who will place a higher priority on different aspects of the project.  This again allows the team to develop a contingency strategy.  Even more important at this time is to develop a scope change strategy.

A scope change strategy can be broken into 3 parts:

1. Approvals – who needs to agree to the change in order for it to go ahead
2. Criteria – what conditions have to be met to accept the change (ie safety, cost, quality)
3. Impact – analysis of the impact it will have on the 3 success criteria; cost, performance and timeline

Communicating the strategy to team members and stakeholders will help reduce tension and ensure a fair process is being used, making things overall go smoothly.

Terms of Reference - G20

During June 2010, Toronto Ontario was the scene of the most recent G20 Summit.  Unfortunately, as per standard these days, it saw protests that turned violent.  As too is common, an inquiry has been called into the police actions.

What does this have to do with optimization, projects, manufacturing etc?  Well, I was interested to hear them say on CBC that a person has been appointed who's sole role is to define the terms of reference of the inquiry.  For those of us in the project management world, this is another term for project scope.

Defining these terms of reference is crucial for the inquiry.  It will determine the type of questioning, how far along the chain of command, who will be questioned and how far back into the planning of the Summit they will go.  What is truly interesting is that time will be allocated to develop these terms, considering all the stakeholders involved and the long term impact it could have on Summits all over the world.

How often do we in manufacturing ever take the time to truly develop the scope of projects?  Have we ever faced the wrath of a poorly defined scope?  How often have we seen the scope change significantly in the middle of a project?

Most projects will not have the global attention this inquiry could have, nor would they have the political intrigue, nor the breadth of stakeholders.  Therefore, one would say that a project does not need to dedicate the month or two to developing a scope as this one does.  But, each project needs to have some time spent on developing a good scope.  Next time you work on a scope, think of the impact of a poor scope and spend the time to make sure yours is narrow yet broad, defined but loose enough to bend as more information comes in.  Good luck!

Chartering a Project

While waiting to hear back about the budget, the Munleytown team decided to go ahead and launch the aseptic packaging line project. According to the messages sent from head office, especially marketing, this new line was in direct alignment with the corporate strategy for 2010 and the next 5 years. So, the risk of the project being cancelled seemed low.

To make sure the team was headed in the right direction and all together, Eva had the team work on developing a Project Charter.

A project charter basically consists of the title, a description of the issue or situation, the impact it has on the business and what the key objectives are. It outlines the scope of the problem, overall timing, key metrics and milestones and the who the key stakeholders are.

While a charter should be an evergreen document, Eva knew it was essentially a contract between her, the team members and the key stakeholders. If something changed, whether it be scope, timing, personnel or even the objectives, the charter would need to be updated, reviewed and signed off again.

The first go-round for the team produced a charter with a lot of holes. They just didn't have enough information. Who should be involved? What was the impact of the issue? When did it need to be done by? What is the right amount of stretch in setting the goals? What are potential risks to the project itself? But now the team was in agreement about what questions needed to be asked and was able to fill in the blanks during the 2nd chartering meeting.

Leaving the 2nd meeting, Eva felt good about her team and a lot more confident that they were all heading in the same direction to solve the problem.