Tag Archives: Project Scope

Your Project Will Change

You led your team through a very thorough requirements gathering process. There was brainstorming and walk-throughs of the product functionality. Multiple groups contributed and reviewed the results. Additional analysis and review went into deciding which of the requirements would really make it into the scope. There was plenty of intelligent debate. And now finally, the project scope document has been signed.

Everything has been agreed upon and there will be no changes. Right? Wrong! Your project will change. You might begin to think, “What does she know? She wasn’t there. She did not see all of the work that went into agreeing upon our project scope.” You are right. I have not been following you. Still, your project will change.

What you have done is helped to ensure that the changes that occur either stem from unforeseeable circumstances or are truly useful enhancements or result from changes in the organization or political climate. Your project will change.

Even with the best planning possible, random things can occur. Previously stable business partner can go out of business and cause you to seek out new suppliers. A certain type of material may not hold up to testing. A new regulation may be imposed on your industry. A product may not function as designed. Testing might reveal a flaw. Sometimes unforeseen events bring about change.

As the project moves along, your team members will develop a better understanding of the work that is being performed. Your customers will develop a better understanding of what they really need. New ideas will evolve. You are not going to tell all parties to stop thinking, to stop coming up with new ways to make your product or service even better. You want the good ideas to keep flowing. If a change to the project is valuable enough, then a change request should be approved and the change should be incorporated. Your project will change.

To your surprise, your project sponsor who seemed happy and stable in her position announces that she has accepted a position outside your organization. Her replacement supports your project, but has different ideas about the project objectives and about what you and your team should really be creating.

Say it with me now, “My project will change.”

And it is going to be all right. The amazing work you did with your requirements and your scope document was well worth the effort. By spending time gathering requirements and agreeing upon scope, you have created a good baseline for the changes that will come. You and your team will recognize change. You will be able to have intelligent conversations about what these changes mean to your project.

Let the changes come, you are ready for them.

5 Steps to Sighting In Precise Project Scope

When you come to initiating a project, determining the project scope can at the outset seem like an easy thing to do. After all everyone must be clear on what the project is delivering because otherwise there wouldn?t be project, right?

Sadly no. Accurately determining the scope of a project is one of the hardest tasks in initiating a Project. It may not seem so at the time. In fact at first glance it appears to be simplicity itself. However beware. Get this wrong or leave any possibility for ?interpretation? and you will be well on the way to a flood of Change Requests and then the dreaded Project Failure.

Now many Project Managers think that the more vague they detail the project scope as, the better. Firstly it stops all the arguments with project stakeholders over scope and allows the project to actually get started. After all, at the initiation stage it is usually still unclear what the project is able to deliver, because requirements haven?t been documented yet. But the problem is that by doing this you are simply storing up numerous problems for the future.

For example, well meaning business stakeholders have a knack for changing their minds once the project initiates. By that I mean they keep demanding you deliver more functionality, but of course for the same budget and to the same timeframe. Unfortunately since the scope of the Project is vague, it?s virtually impossible for the Project Manager to insist that deliverables for the project have changed. It then becomes an uphill battle to fight against the constant scope creep.

To stop you getting into that position there are 5 steps you should follow. These are:

1. Insist on proper Business Stakeholder input from Day 1. Yes they will kick and scream but if the project doesn?t deliver, it?s your reputation on the line.

2. Ask the Business Stakeholders to tell you what they think the Project is delivering. Do this individually as it will make it clear where the differences of opinion are.

3. Once you have the high level information, move down into the detail of the deliverables. At this stage get the input of the Business Analysts and Development Teams so you can quickly clarify what is achievable in the timeframe.

4. Remember that what is Out of Scope for the project is possibly even more important than what is In Scope. So don?t overlook it.

5. When you have completed detailing the project scope, remember to pass it by the Business Stakeholders first, for their comments and feedback. Once you have their buy in, your project stands a good chance of delivering.

Of course there is much, much more, but at a high level following these steps will give you a chance of not falling at the first obstacle.

my-project-management-expert.com provides additional tips on how to complete the vital Project Scope Statement and deliver this by writing a Project Scope Statement in a Project Initiation Document. You will also find much more useful information there on how to deal with the whole complex area of Project Scope and ensure it doesn’t overwhelm your project or cause it to fail.

Project Communication

flickr photo by loop_oh

flickr photo by loop_oh

Effective project managers communicate about 90% of their time. There are no misunderstandings; there are only failures to communicate. Project managers communicate by using different mediums to convey a message. The message might be to an individual, a selective meeting with team leads, project sponsors, or the whole team collectively. It is truly critical for project managers to get the message across right the first time to avoid failures in the communication process.

There are three key components in projects known as the triple constraints, scope, schedule, and budget. During the planning process, it is the project manager?s primary responsibility to define the project scope using the work breakdown structure (WBS) to do so. The WBS consists of a hierarchical numbering system that accompanies a brief node description. The WBS is an aid to facilitate stakeholder communication. The WBS dictionary communicates the full details (inputs, outputs, assumptions) of each WBS work package at the level of which technical scope is controlled and delivered. Project managers and their teams decompose or subdividing the major project deliverables and project work into smaller, more manageable components. The technical scope baseline is fully communicated and configuration managed after completing the Project Plan, WBS, and WBS dictionary.

The detailed schedule proceeds semi-concurrently with the WBS dictionary activity. A detailed schedule reflects the technical scope and is created through a series of iterative processes that progressively elaborates the WBS into lower level sub-activities. Control accounts are established at the reporting level 3 of the WBS. Cost accounts are established at WBS level 4 of which technical scope is controlled and delivered as defined in the WBS dictionary. The schedule development processes are 1) activity definition, 2) activity duration estimation, 3) activity dependencies, 4) activity resource assignments, 5) critical path review, 6) resource loaded network (RLN) acceptance. These processes are conducted by the project technical experts in conjunction with project controls to ensure a bought into, agreeable, realistic, and formal plan. The project manager must accept the RLN before establishing the schedule baseline.

The RLN is fed into the earned value budget application such as, Deltek Cobra, to achieve costing and performance metrics. Up to this point, scope has been defined, communicated, progressively elaborated, and logically assigned resources to achieve results. During this process is when the WBS level 4 basis of estimating (BOE) rationale is captured of which technical scope is controlled and delivered. The primary function of a BOE is to capture the rationale behind the development of the WBS level 4 estimates e.g. specific tools and techniques used during the development of the time and cost estimates to produce the deliverables defined in the WBS dictionary. Cost metrics are collected by project controls and then applied to the time estimates provided by the technical experts in the RLN. Earned value performance measurement techniques encompass the RLN using 1) 0/100 for 160hrs or less sub-activities, 2) 50/50 for 160+hrs to max 320hrs sub-activities, 3) interim milestones for 320+hrs using ?steps? and corresponding finish dates to compute weighted % complete of sub-activities, 4) % complete for agile sprints that are substantiated by the overall deliverable requirements complete, and 5) LOE for level of effort sub-activates. Concluding these activities produces the initial project costs. Contingency reserve is then applied by technical experts and the project manager to critical path activities therefore producing the project budget and the cost baseline. Management reserve encompasses the cost baseline for high probability ? high impact risk events.

The project manager combines the technical baseline, schedule baseline, and cost baseline into one performance measurement baseline (PMB). The project manager uses the PMB to communicate project performance and acceptable baseline variance to all stakeholders. The PMB may demonstrate the way to project completion, but it is the project manager?s ability to understand that there are no misunderstandings; there are only failures to communicate that keep the project on track.