Project Seminars

Managing With Parkinson’s Law

Another consideration when it comes to creating estimates is Parkinson's Law. Parkinson's Law states that work will expand to fill the amount of time it is allotted. Here's an example: you, the project manager, are working with your project team to determine how long each activity will take to complete. Suzie knows that an assignment she'll be completing for the project will probably take 32 hours to complete. Suzie, however, knows that there might be some problems, some snags, or some other delay, so she "pads" the duration estimate by eight hours and tells you it'll likely take her 40 hours to complete the assignment.

Guess what? It'll magically take 40 hours to complete the work. Suzie will either complete the work in 32 hours and not tell you she's done because she reported it'll take 40 hours or she'll ease through the work and use all 40 hours to complete the 32-hour assignment. Another possibility is that Suzie won't start on the actual work until hour eight and she'll pray and hope nothing goes awry in the assignment. The worst possible scenario is that she'll wait until hour eight to begin, things do go awry, and she'll require more than the allotted 40 hours for the work.

There are multiple strategies to combat Parkinson's Law, one of which is the three-point estimate. Another approach is to use a "management reserve" which is a pool of time that all activities may borrow from should their activities go over the allotted completion time. In other words, if a project is estimated to take ten months to complete the project manager will allot approximately 15% additional time for management reserve. The project will, in this instance, take eleven and a half months to complete. As activities are late the time is subtracted from the management reserve. To use management reserve, however, the project manager and the project team must agree to be accurate and as honest as possible when estimating how long activities may take to complete.

More Stuff For Your Scope

And here are three more things to put into your project scope:

Project constraints. A constraint is anything the limits the project manager’s options. You must be done in two years. You must not exceed four million dollars. You must use COBOL. You must use Indiana limestone. Anytime you see the word “must” or “demand” then you know you’re dealing with a project constraint. Technically, all projects have at least three constraints: time, cost, and scope.

Project assumptions. An assumption is anything that you believe to be true, but you haven’t necessarily proven to be true. For example, in construction an assumption is often made that summer months are better than winter months for building. Or you may assume that the software you’re creating will work just peachy with Windows Vista. Or you assume that all of your project team members are happy to working on your project. As you can imagine, assumptions can become risks.

Initial project organization. Who’s who in your project. This portion of the project scope statement defines the project manager, the project team, the project customers, and any other project stakeholders. You may also identify the reporting structure in this portion of the project scope statement.

Scope Checklist: Items 1, 2 and 3

So what exactly does a project scope statement include? I’m glad you asked, otherwise this list would be just silly. There are 16 items that a project scope statement should include, here the first three:

Project objectives. Objectives are the goals of the project – the measurable, quantifiable goals of the project. Think of time, cost, quality, technical requirements, blueprints, and product acceptance criteria. I stress the word quantifiable – avoid loose terms in your objectives such as fast, good, satisfaction, and other subjective terms. What’s fast to you may be slow to your customer. If you can attach a metric to it you need to.

Product scope. Remember the product scope – the vision of what the project will create? The product scope and all of its features and functions are included here.

Project requirements. Let’s face it, your project will have some requirements. You can identify a project requirement as anything that “must” be met, kept, or deliverabled. The project must not exceed $750,000. The project deliverable must be able to interface with SQL, Oracle, and Access. The project deliverable must be blue. Requirements are often, if not usually, tied to the product scope and the project objectives.

Detailing the Project Scope

The project scope statement is a document that defines what the project is, the project deliverables, and the work that the project team (and likely contractors) will have to do in order to create the identified project deliverables. The major purpose of the document is to communicate with the project team, the project customers, and the project stakeholders a common understanding of the project’s purpose, goals, and objectives. The project scope statement, as I’ll dive into one moment, also serves as a launching board for additional planning by the project team and the project manager.

The project scope can be a large document or a simple one or two-page manifesto. So how big does this thing have to be? Here’s a heuristic you can rely on: larger projects typically require more detail than smaller projects. In other words, the bigger the project the longer it’s going to take to create the project scope statement, and the more information you’ll need to include in the document.

Real World Note: I admit I’m painting some large brush strokes here. Most organizations are going to have project scope statements available from past projects – that’s part of your organizational process assets. There’s nothing wrong with using a past project’s documents as templates for your current project – work smart not hard. And if your organization has never, ever completed a scope statement before? You’ll need some additional planning time to create the project scope statement. Don’t be surprised if your project scope statement goes through several rounds of revisions – it should.

Twice the Fun: Two Scopes

Technically there are two scopes when it comes to project management:

Product scope – This is the vision or expectation of what the customer has in mind for you to create for them. For example, imagine your dream home; in your mind’s eye you can probably see your house, the material is made out of, the kitchen, the den, the bedrooms, and so on. You can probably also imagine how you and your family would use and live in the home. This is the product scope – all of the features and functions that the project is to create for you, the project customer.

Project scope – This is all of the resources and work required to create the product scope and the ancillary deliverables of the project. This the labor, plans, blueprints, documents, and effort to create the vision the project customer possess.

The product scope and the project scope support one another. If the project team is doing work outside of the project scope then the customer is not going to get the product scope that she envisioned. If the customer doesn’t know what the product scope is then the project manager and the project team are going to have a tough time creating the project scope. These two scopes support one another. The project scope statement is identified by completing a product scope analysis, since it reveals what the project must create.

Real World Note: Often the product scope is already designed before the project manager and the project team get started on the project. The product scope is concerned with the features and functions of the project deliverable, while the project scope is concerned with the work to create the project deliverables.

Cope with Your Scope

During the initiating process you and the project customer created requirements that defined the basic ideas of the project. This document is elaborated upon, and the project scope is now created. In addition to the preliminary project scope statement, you’ll use the project charter, historical information if you’ve done projects like this one before, and approved change requests that may have trickled in. (Here’s an example of how you won’t have many change requests affecting the project scope early in the project, but as the project moves through its execution change requests can become more common.)

Defining the Project Management Life Cycle

 As I know you know, project life cycles are unique to the project. They are not universal to all projects. What is universal to all projects is the project management lifecycle. Yep, I said universal to all projects – from the creation of the pyramids in Egypt to the design of some schmancy software you might be creating right now. All projects live and die by the project management lifecycle.
The project management lifecycle is comprised of five process groups. The bulk of this book focuses on these five process groups and all the fun activities you’ll do in each group as a project manager. Here’s a quick overview of what type of work happens in each of the process groups as you move through the project:

1. Initiating: Projects are selected, authorized, and chartered. Fascinating.
2. Planning: Projects demands lots of plans, so you’ll create project management plans through 21 planning processes.
3. Executing: Once you’ve got all your project plans and project documentation your project team is ready to execute the project work.
4. Monitoring and Controlling: The project manager has to keep an eye on all the moving parts of the project – that’s what happens in this process group. Control freak!
5. Closing: Sooner or later the project gets closed. These activities document the project’s performance, the project’s deliverables, and the project’s lessons learned.

As you can see in Figure 1, there are iterations of planning, executing, and monitoring and controlling. Think of a project you’ve worked on in the past. When the project team was executing the work, or a project risk was discovered, or work was done incorrectly, what would do? Well you may have pulled out your hair first, but you would go back to planning. Planning is an iterative process group throughout the project.
The project management lifecycle is universal to all projects, but it does act in conjunction with the project lifecycle. Recall that the project lifecycle is comprised of phases. In a very large project, such as building a skyscraper, the project management lifecycle can be imposed on each phase of the project. This allows for tighter control and forces the project manager to document each phase’s performance before the next project phase is allowed to begin. Nifty.

Real World Project Management

A budget estimate usually has a range of variance of -10% to +25%. So the $80 million project example could actually cost the organization as much as $100 million or as little as $72 million. The definitive estimate for each project phase usually has a very tight range of variance of -5% to +10%. Notice I said “usually”? Your organization might laugh at those percentages and give you a whopping one percent range of variance – or less. Now that’s the real harsh world.

Working With Phase Gates

Within the project lifecycle and attached to the project phase you may have to work with cash flow forecasting. Here’s the pitch: you’re managing an $80 million project that’s scheduled to last five years. Management and your customer are probably not going to just write a check for 80 million bucks and send you on your way. More likely you will be completing a phase-gate estimate and will be working with step funding.
So what’s a phased-gate estimate? Glad you asked. This is an estimate type where you provide a budget estimate for the entire project, as in $80 million dollars, but then you prepare a very detailed phased-gate estimate for the phase that’s about to begin. This estimate is very detailed and shows management and the stakeholders what they’re getting for their money during this project phase. In our $80 million project a phased-gate estimate for the current phase may be five million. The monies spent in each phase totals $80 million.

Phases and Kill Points

Completing a phase doesn’t necessarily allow the next project to phase to begin automatically – though it often does. What may be attached to the end of a project phase is called a “kill point.” A kill point isn’t as scary as it sounds. It’s an opportunity for management, or often the project customers, to look at how the project is performing. If things aren’t going so hot on the project, and by not so hot I mean that the project is late, over-budget, or quality is suffering, then the project can be killed at the point.
Sometimes a project is performing well, but a kill point is enacted anyway. There can be legitimate reasons for killing a project regardless of excellent performance. Consider a leap in technology that supersedes the technology a project may be implanting; it would be foolish to continue implementing the technology that’s outdated, so the project is killed instead. Research and development projects are other examples of projects that are killed, because the research done through the end of a given phase has warranted the project to continue. There is no sense throwing good dollars after bad.