Forward Momentum: Delivering Results

by Bruce Beer, PMP

Note: This is part 3 of a 3-part series.

The first in this series of Keeping on Track blogs dealt with how to keep your project on track with regard to time, the second dealt with how to stay within budget, this final blog in the series now looks at keeping to defined scope and how to avoid the dreaded scope creep!

As with time and cost, to be able to meet your scope baseline you first have to establish it. Project implementation can either be based on a firm, solid bedrock of requirements or it can be built on the shifting sands of indecision, false assumptions and differing interpretations that will eventually sink the project and lead to project failure, recriminations, accusations, heated arguments and potentially a visit to the unemployment office for the PM. So what are the basic requirements for a solid scope baseline and how do we create one?

The first step, often omitted, is to identify ALL project stakeholders – anyone who impacts or is impacted by the project. “Why is this” I hear you ask. Well any one of those stakeholders may have a requirement that is vital to the success of the project, and if we miss this requirement it may take time, money, and added complexity to include it later. So we will interview, perform surveys, have workshops etc. to ensure we get the full set of requirements at this stage rather than during acceptance testing! However, note that not all stated requirements will be included in the final scope of the project because each requirement has to be cost justified.

Once we have identified all requirements we can then start building our project scope by first identifying the deliverables required to meet them, then discussing and agreeing these with the customer (the person paying for the project) to decide which requirements are “must haves,” “wouldn’t it be nice ifs,” and “bells & whistles.” At this stage, if there are any areas of uncertainty, they should be clearly identified as definitely either “In scope” or “out of scope” just so that there is no ambiguity or room for interpretation at a later date. Then we can create the Work Breakdown Structure (WBS) – the heart of all project planning – based on these deliverables, followed by a specification. The WBS together with the specification creates the scope baseline. The purists amongst you will know that there is a third element of the scope baseline, the WBS dictionary, but we will not consider this now.

OK so now we have a solid scope baseline. We know exactly what it is the project has to deliver and have created a detailed project plan based on the WBS. All we have to do now is to ensure the project meets the three baselines. Controlling and meeting the scope baseline is probably the easiest of the three baselines to achieve as there is one main process used to control scope – change management. This means that ANY deviation from the original specification will need to be formally requested, evaluated and authorized by the customer before it is implemented. Some people may think that any change that does not involve additional time or cost does not need to go through the formal rigor of change management. These are probably the people out on the street looking for a new job wondering why their life took such a sudden and unexpected downturn.

Let us consider an example where a customer wants to change the length of an address line from 25 to 30 characters. Let us assume this is recognized before the programmer has written that section of code, so there will be no additional time or cost just to extend that field. So why bother to create a formal change request for such a simple change? OK, well let us look at this from three main viewpoints: ripple effects, acceptance and stakeholder satisfaction.

1.       Ripple effect

If there is no formal change management process, the programmer extends the address line and keeps this as a well hidden secret because they do not want the PM to find out they did it. What harm can it do? Let us suppose the address is part of the order input screen. Other areas of the software such as invoicing will be working on the specified basis of 25 characters per line, so all printouts, disc records, searches, etc. would use this basis. So the ripple effects of this apparently innocuous change can be many and serious.

2.       Acceptance

Now let’s look at acceptance for the above. During acceptance testing, the person performing the test will look at the specification (25 characters), incorporate any formal authorized changes (none), and will expect the test to meet this combined requirement (25 characters). The tester puts in a 24 character address, expecting it to be processed correctly. Then they will try a 25 character line with the same expectation. Then they try a 26 character line and expect it to fail and produce an error message, and guess what, it doesn’t do this, it accepts the over-length line without any problem. The tester will then declare that acceptance test has failed.

Now let us consider the correct procedure. The customer creates a change request for the address field to be changed to 30 characters and gives it to the PM (all change requests must go to the PM). The PM logs it and sends it out for impact analysis. The analysis comes back identifying other parts of the project that might be affected by the additional characters and additional changes that might be required. Then it might say that there is minimal or no time or cost impact. The customer would formally authorize this change and the change is implemented. The acceptance tester will see the initial requirement of 25 characters, will have the authorized change to 30 characters and will test accordingly, and lo and behold it passes acceptance.   

3.       Customer satisfaction

Now let us look at customer satisfaction. Consider a fairly substantial change. If the change does not go through the formal process it will not be formally approved, so in addition to failing acceptance we now have additional time and cost to worry about. We as PM are measured against how well we perform against the project baselines (customer expectations) for scope, time and cost, so immediately the PM now fails on all three baselines. If there had been a formal approved change request, the project would then meet the scope requirement (initial specification plus formally approved changes). If the project took longer than initially planned but there are formally approved change requests providing an audit trail for the additional time to perform changes, then the initial time estimate plus authorized additional time is the new measure against which the PM will be judged. The same with cost – the initial cost plus approved changes is the new measure for the PM, so providing they meet their initial estimates plus allowances for formal changes, all is good and a pay rise is on the horizon. In conclusion, formal change management creates an audit trail of authorization for any change to the original baselines.

Most companies these days will have a formal change management process with which the PM should be familiar and use. One of the key areas discussed by a PM during the project kick-off meeting will be to review, explain and distribute copies of the change management process to all stakeholders. The PM should explain the serious repercussions of not following this process! If the customer is not at the kick-off meeting, the PM should review and agree the process with them prior to the start of implementation to ensure it is understood and agreed.

Final thought: if you have read all these blogs you will know they are highly interrelated. If time or cost start going out of control, one option depending on constraint priorities is to de-scope the project to bring it back on track. De-scoping will involve looking at “bells & whistles” first to see which can be removed with least impact on the end product. Once all of these have gone, the next object of your gaze will be the “wouldn’t it be nice ifs.” If you reach the end of these and are left with the prospect of de-scoping some of the “must haves,” you have a serious problem. Removing any “must haves” will affect the viability of the project, so at this stage scope cannot be reduced further. You will need to review cost and time to reach the optimum results.

By Bruce Beer, PMP

Note: This is Part 2 of the Keeping Your Project on Track series. Click here to read Part 1, Keeping Your Project on Time.

The first in this series of “Keeping Your Project on Track” dealt with how to keep your project on track with regard to time. Now let us turn our attention to one of the other key baselines – cost. If you have ever managed a project that has come in over budget you may already realize that this is not entirely or fully appreciated by management! So, how do we keep within budget?

Before we can hope to keep within budget, the first thing we must do is to set a realistic and comprehensive cost baseline, or budget, to keep within. Everyone knows that one of the key elements of cost is the cost of your resources. Most of us know that to determine this cost we need to identify ALL scope, create a Work Breakdown Structure once we have identified all deliverables, break deliverables down into activities, allocate a resource or skill level to that activity, then estimate a duration. At this stage we can calculate a cost for each activity by multiplying the daily rate for the resource due to perform that activity by the duration. Once this is done for every activity (strongly suggest you use a scheduling tool such as Microsoft Project or similar) we can aggregate all these costs into one overall cost for the project – a bottom-up estimate of resource costs.

What many people don’t realize is that this is NOT the budget – there are other costs involved to create the budget, and some can be significant. These include items such as:

• Project Management/PMO costs
• Subcontractor costs
• Outsourcing costs
• Cost of quality (design, measurement, hardware, software, testing, inspection, etc)
• Risk contingency
• Cost of communication (time to create, disseminate, read, respond, etc)
• Costs of hardware, software, applications, tools, etc. you require to complete the project
• Cost of facilities and utilities, etc. if they are allocated to your project
• Travel costs (transport, accommodation, living expenses, etc)

Once we have identified all estimated costs for the project based on a firm solid knowledge of scope, we need to ensure the unexpected does not come along and rock our financial boat. Two key elements that can throw our carefully created cost budget off track are additional costs due to risk and changes.

To ensure we have allowed ample funds for known risk, we should ensure good risk management practices are followed – identifying as many things that can go wrong as possible, allocating the relevant amount of contingency funding for each, then combining these into a project risk contingency fund. 

Change itself is often good for a project – it can breathe new life into a project, improve functionality, and generally make the end result better. However, the downfall of many a PM is the dreaded “scope creep” or uncontrolled change. Each PM should have access to their company’s formal change management methodology, or if there is no such thing, create and distribute one to all stakeholders. Everyone should know that if they want a change they should request it in writing and give it to the PM (always the PM, never anyone else). The PM will log the request to enable them to track progress, ensure an impact analysis is completed detailing any additional scope, time, and cost required to implement the change, then give this to someone who is qualified to authorize the change (normally the customer). Providing a PM does not implement any change at all without prior authorization, their project (and probably career), are as well protected as possible.

In the final reckoning, when managers ask whether the PM has met their cost targets, the PM should add all the authorized additional cost of changes to the original budget and compare that to actual cost. Providing the PM has done a good job on risk contingency planning and rigidly enforced change management, they should be looking for promotion, pay raises, bonuses, appreciation from your management, and an enhanced reputation. Failure to identify and cost all scope to be included in the project, failure to identify and allow for risks that can try and throw you off track, and failure to manage change correctly will certainly lead to all things unwanted, like over time and over budget project delivery, and long waits in the employment agency whilst looking for your next job.

Once a PM has identified the budget correctly allowing for risk and rigidly controls changes, then regular monitoring of costs during the lifetime of the project will enable identification of problems at the earliest opportunity. So what do you do if, despite excellent planning, costs start to exceed estimate and you can see defeat staring you in the face? If this is a cost driven project where cost is the priority, the first step would probably be to remove some scope until costs come back under control. When defining scope you probably defined the “must haves”, the “wouldn’t it be nice ifs” and the “bells & whistles”, so when looking for some scope to remove, we can look first at the bells & whistles, then possibly at the wibnis. Using Earned Value Management throughout the implementation of the project would help identify cost issues as early as possible, thereby enabling you as PM to step in and start corrective action as soon as possible.

To summarize, the key to bringing projects in on budget are:

1. Good scope definition to ensure everything is included during cost estimation
2. Good estimation of ALL project costs, not just team resources
3. Good risk identification, quantification, and contingency funding and planning
4. Very tight change management throughout the project from all stakeholders (including the customer!) such that no changes are implemented unless correctly authorized
5. Regular cost monitoring during the life of the project, resulting in prompt action to correct slipping costs and bring the project back on track.

By Bruce Beer, PMP

Note: This is Part 1 of the Keeping Your Projects on Track series. Part 2 is Keeping Your Project Within Budget.

You want to be seen as the latest wunderkind of your Company and to bring your new critical project in on time, leading to much applause, plaudits, admiration, and maybe even a pay rise! You did a great Microsoft Project schedule, and even highlighted the Critical Path, so now you are in business and can almost guarantee success – yes?

After a month, you have been focusing on your Critical Path and making sure these activities receive your full attention – this must surely ensure you come in on time, yes?

The answer to both the above questions is no! There are certain fundamentals that you as a project manager need to understand before you can “Manage” your project to a successful conclusion.

You must know the priorities of your triple constraints – Time, Cost, and Scope.

Is this a Time driven project where you may have a drop dead date for project completion? For example the lease on your current hardware runs out on an immovable date and you need to have a new system using the latest software running on your new hardware by that date.

Is it a Cost driven project where there is a fixed budget which just cannot be exceeded on pain of death or job termination? or

Is it a Scope driven project where the scope defined in the scope statement is absolutely critical? For example, migrating an old system onto a new platform where total pre-existing functionality needs to be retained.

Not only must you know your highest priority but you should also know the order of the remaining two  - you need to know your highest priority, lowest priority, and the one in the middle before you start detailed planning.

Why should you know what the triple constraint priorities are? Well, for example, if your project is time critical but you treat it as cost critical, you might do an excellent job and end up coming in on cost but after the due date – which would not be considered successful. Similarly, you might bring a cost driven project in on time but overshoot your budget – again not advisable for long term career continuation.

You must keep your project schedule updated.

Your critical path can get out of date and be potentially useless very quickly. The Critical Path might shift at any time leaving you highly focused on the old, out of date, and incorrect path – this is unlikely to lead to success!!

Keep activity lengths short for best monitoring and control.

On normal projects it is recommended that you keep activities to 10 days or less (if an activity is greater than 10 days, break it down into sub-activities so each one is less than 10 days) and aim to update your schedule with “real life actuals” on a weekly basis.

For time driven projects, some other areas you as PM should consider to ensure maximum chance of bringing your project in on time include:

• Time estimates should be as realistic as possible and provided from the best source. Do not be optimistic – rarely is optimism rewarded.
• Carefully evaluate and include time risk, especially on Critical Path activities.
• Never plan on working overtime. This is a contingency you might need to use during execution.
• Do not accept unrealistic requirements from your managers or customers. Better to suggest realistic alternatives that can be achieved rather than accept them and fail.

Note that as always, the root of project success is in the planning. If we follow the above suggestions to create a realistic schedule, we know the initial and most recent critical paths, and we recognize and know what to do if the project starts to slip, we stand a chance of bringing our time driven project to a successful conclusion.  

Once started, if your project starts slipping and you have detected this ugly fact at the earliest opportunity, for a time driven project where scope is the middle priority and cost is the lowest, a sequence of remedies you might consider, in order could include:

a)       Look for someone already on your project with the appropriate skill set who is available, is not on the critical path, and has sufficient slack, to help out with a critical path activity. Temporary addition of this resource to the critical path should bring your project back on track retaining full scope with minimal additional cost.

b)       If there is no one suitable available in your project, you could look outside your project but within your company to keep additional cost as low as possible.

c)       If this is not possible, look outside the company for short term consulting – this may initially require some time in getting the resource up to speed but eventually they will be fully productive and haul back the end date to where it should be, but at additional cost. (Note scope is a higher priority than cost.)

If the second priority had been cost rather than scope, then your first point of attack might be to remove some scope to bring the project back on track. There may be some “bells and whistles” that could be eliminated without affecting the overall effectiveness of the project. This should not involve extra cost.

To enable you to do the above, it would be a good idea to know the full skill set of every project team member, even if they are not using all their skills on this project. It would also be a good idea to be familiar with other projects going on in your company and network frequently with the other PMs so that short term transfer of resources between projects is made relatively easy and will improve the overall success of projects in your company. It does, however, mean that other PMs in your company should be using critical path analysis on their own projects.

There is a great deal more to managing a time critical project than outlined above, but this should act as a good starting point.

by Bruce Beer, PMP

In Part 1, we introduced the difficulty of trying to create a quality plan on complex projects without historicals. Here, we complete the series by discussing the objectives and components of a quality plan.

What is the overall objective of a Quality Plan? I would say it is a plan of how we intend to meet the project quality objectives (quality plan), identify variances (quality control), and act on those variances (quality assurance) to implement any corrective measures required.  So the plan would normally have a “general” section that describes the quality methodology, the company’s overview on quality, i.e. their quality policy, maybe quality requirements in the specific marketplace in which the project will operate, and possibly how to ensure quality during subsequent operation, if applicable.

Some of the basic elements might include quality metrics, success criteria, quality checklists, and tools to be used across the organization. For example, if you are creating the quality plan for a program, you may want to specify what tools should be used, such as MS Office version xxxx. We have probably all experienced the frustration of having a Word document sent to us from someone who is using a later version – we can’t read it! Similarly, using MS Project across a program should have everyone using the same release to ensure data can be communicated and read by all on the program. Where you have many servers around the globe, it might be quite a good idea to have them all on the same OS, with the same version or release number, and patch level etc.

In conclusion, I would say that a quality plan should be considered for every project. The size and complexity of the plan would depend on the size and complexity of the project. But in minimal terms it should identify the deliverables to be produced, metrics to be measured for each deliverable, the overall quality policy, the tools to be used, and how to report and handle variances. This should be a good baseline for attaining the best quality on your project.

What have you included in your quality plan? Were you able to start from templates or historical plans, or did you have to start from scratch?