In this week’s episode of Project Management Paradise, I speak with Patrick Kennerson from Bulldog Consulting about the importance of a well-defined Project Scope.
In this week’s episode of Project Management Paradise, I speak with Patrick Kennerson, a Programme Controls Specialists at Bulldog Consulting about the importance of a well-defined Project Scope.
Patrick has a very interesting background in Project Management working in industries such as software, aerospace, nuclear and construction. Kennerson started out in the Software Industry as a Software Tester, and then became a Programmer. He continued onto to project management of large-scale software before making his way to the Aerospace Industry. From there he went onto the Infrastructure Industry, Nuclear, and finally Construction. From his multidisciplinary background, Patrick picked up ‘core truths,’ including insight in project scope, scope capture, and change management. He explains how In any project management, project controls are mission critical just for success. Most issues in project management tend to be around the core fundamentals in respective of the industry.
In this interview, Patrick shares some great insights regarding project scope, scope capture and change management.
The podcast is sponsored by Cora Systems providers of enterprise project and portfolio management solutions and services to government agencies and large-scale global organizations. To see how Cora can help transform your organization why not request a free personalized Demo.
Subscribe to Project Management Paradise via one of the links above or on the right and you’ll automatically receive new episodes directly to your device.
Excerpts
How do you define ‘Project Scope’?
Your scope should be defined and aligned with the work breakdown structure (WBS). A good project scope should be more like the bible, and less like a novel. Your scope shouldn’t be a rambling narrative. It should look like chapter and verse, so that you have the exact WBS illustrated in the scope at a particular level. When you’re defining the scope, you should be able to go all the way down to Level 3, and see the scope index to the Level 3 WBS.
More W and less BS.
There should be less narrative and more technical writing.
A good WBS scope should have:
- The definition
- The WBS dictionary
- The identification of what the scope refers to
- What’s included/excluded in the scope
- Define the start/end date
- Address how the scope will be tracked within the schedule
Additionally, you should ask yourself:
- What method are you gonna use to track the progress of that scope? By percent complete? Or milestone completion?
- What are the assumptions on that scope?
- What are the risks associated to that scope?
- What are the inputs associated to that scope? What are the outputs associated to that scope? What is the cost index to that scope at level 3?
How do you maintain control of the scope’s definition and what the project does NOT include?
Scope control is difficult at Level 0. If you start at Level 3, then you are speaking to a specific thing. For example, if you’re saying, “the engineering of the sleeve for the drilling apparatus,” you can then say, “this does not include the platform.” The definition is only about the sleeve. The actual definition easily enables exclusion.
What defines various ‘levels’?
One of the biggest issues in project management and project scope are losing sense of a Level 3 definition. Essentially, it should have the discrete activities that make up that work, but not be a rambling narrative.
It is important to have created a correct scope definition when you start to collect costs. If defined properly and at the right level, then you will only collect costs that pertains to that singular activity. If you have the set level too high, then you start collecting costs for other things that have very little to do with the core scope.
For example, a $500 toilet seat. It’s not really just the toilet seat that’s costing you. It’s the toilet seat and the design. The level is so high that you’re actually collecting a lot of costs that don’t tell you the true cost of the activity. The level has to be low enough to have the specific activities that are going to be used to accomplish that work.
A Defined Scope
If you can start with a properly defined scope, then you’re going to be almost 75% more successful in an enterprise project. Scope is the core that influences everything else: the schedule, the cost collection, the inputs, and even the risk. If you define the scope at Level 3, set a good start/end date, specific activities, define the risk to that scope at that level, you actually have a start and an end date in order to retire that risk. Risk can be problematic as it can migrates until the end of the program when assigned at a level that’s too high. You will never know when the risk has actually been eclipsed.
Other Consequences of Poor Project Scope
Without a properly defined scope, you start to lose track of the various pieces in a project. Poor project scope can impact all the way from delivery, to cost collection, and ultimately to failure. If you don’t define the scope properly in the beginning of a project, then you will encounter huge amounts of change such as incorrect and increased costs, and more required funding.
Scopes DO Gather Dust
It goes back to that old saying of measuring twice and cutting once. The more time you spend defining the scope and making sure you included all of the scope, the more the project will benefit.
How Much Time Should You Spend Defining the Scope?
There is no definite answer. A gateway process is where you define the scope systematically as you go through the different gateways. This process should ensure that you have all required data before you go to the next phase of the project.
If you’re using the gateway process correctly, and defining the scope as it goes through, then it’s ready when it’s ready, rather than a particular amount of time because of the complexity.
Milestones
More milestones, less tasks. If you look at how deliverables work. What you want to track when you’re going into the program is what you delivered, not the amount of effort that you put into NOT delivering. The more time spent defining the proper milestones out of the scope, then the better off you are in actually detailing true progress. Write the scope, and then glean from the scope the actual tangible deliverables.
What Are the Effects of Good Scope Capture and Change Management?
Again, it all comes down to scope definition. Every year, project interference due to change management is the number one complaint in project management. The influx of change that destabilizes the program, people can’t deal with it, the wheels come off, the cost balloons, and they all put it down to too much change.
In reality, poor scope definition leads to too much change. An immature scope will overload the change system. It tends not to show itself as scope. It tends to show itself as change.
Major Changes in Project Management
When you’re looking at a project schedule of 700 lines, you can’t see anything. You’re not really understanding anything on a 10 page pdf of a complex schedule. It’s not possible. Humans are visual creatures.
Visually displayed data in 3D, 4D, and 5D models will become more and more popular as a way to make sense of projects. Program controls and project management will also start to be done within the model itself.
Notes
Connect with Patrick Kennerson on LinkedIn.
