PM ChangeAgent Commentary
We have long asserted that “doing the right things” in the first 10% of any project is 90% responsible for project success. There are over 250 unpublished “Goff’s Laws,” that provide insights on key parts of this first 10%, and beyond. Those insights include:
“1. You can get away with anything, on the first day of your project.”
The dialogue around this law (really just a common-sense observation) assures that you can move any deadline, ask for any budget, obtain unobtainable talent, or anything you need, if you identify that need on the first day of the project–especially if you have not yet said, “Yes! I will do this project!”
There is a corollary to the above Goff’s Law, that can be of some comfort to those who are assigned somewhat later in the project:
“1a. You can get away with almost anything, on the first day you are on the project.”
Of course, the next 10-15% of the project is important, too, because that is where most project teams establish great business requirements. There is another Goff’s Law about this; this one has been borrowed from other, more-experienced folks:
“12. You will spend 25% of total project effort getting good business requirements. Competent project teams spend most of that 25% in the first part of the project.”
But when is this first part of a project? What is it, that great project teams should assure that they do, during this first part, to assure project success? And, why are these important actions and key results so often skipped? We will begin to touch on these questions in this multi-part (it will require several sections, over time) Change Agent posting.
When Does a Project Begin?
We have discussed this dilemma for years. Different people have different opinions, and the answer you select has significant bearing on what should be present. For example, in Construction, or in most bidding projects (everything from a Defense initiative to an IT subcontract), for the Seller, the project essentially begins with a bid award sometime during the Buyer’s Design phase or stage. We’ll skirt that issue by focusing on an internal-to-your-organization project. To see our perspective, see the scenario we posted over a year ago. Go to When Does A Project Begin? and review that posting. Then, return here.
1. The most obvious question, when did this project begin? At inspiration? When your Manager heard about it? When you first spoke to the Functional Manager? When the team first got together in the face-to-face meeting? Note that each participant may have a different point of view. From the Team’s standpoint, this was a two month project. From the Functional Manager’s view, it took anything from 2-10 months (Inspiration through Benefits Realization).
2. Everyone wants their results faster. We covered this at that link, but what is the best way to accelerate the business benefit? Put a tight deadline on that 2-month project, from July 2 to September 2. Silly? Absolutely, but this is what often happens. Clearly, get the latency out of the period from January 2 to September 2.
3. But, your Manager complains, how can we do that? It took all that time because of all the other initiatives we are working on. Answer: Look–this project returned 3:1! Let’s use some of that return to acquire the talent to do more high-return projects (Realizing, of course, that not all projects are high return. Some are regulatory, some are political)!
Of course, this Scenario is just a simple example. We see many cases where a year or more passes between the March 2 and May 2 events. And clearly, most of your projects take more than two months. But many of them take longer than needed, and return less than you deserve, because your project processes and staffing leave room for improvement.
When we speak of the first 10% of a project, we are talking about the first 10% of project effort. The first take-away from this scenario is to compress the latency out of the front end. If a project is worth doing, it is worth starting quickly.
Another take-away is the importance of the information gathered in that discussion between the project manager and the Functional Manager. Especially important is the information about scope measures, and the business benefits. This allows easier prioritization, both for the project team and the business unit.
There are a bunch more take-aways from this scenario. What are they? And, what do they suggest about some of the most-important things to do, early in every project?
A Comment to the ChangeAgents, 10/16/2011, by Terry Schmidt
You are spot on about the importance of starting a project off right. You never have to recover from a strong start, but can spend way too much time stumbling from the effects of a poor start.
While writing my book STRATEGIC PROJECT MANAGEMENT MADE SIMPLE: PRACTICAL TOOLS FOR LEADERS AND TEAMS (Wiley, 2009), I came across 100 Informal Rules for PM’s compiled over the years by NASA PM’s. I love their Rule #15….
“A review of most failed projects indicates that the disasters were well planned to happen from the start. The seeds of problems are laid down early. Initial planning is the most vital part of a project”.
I’m sure that any experienced PM would agree. Like raising a baby or housebreaking a puppy, if you are systematic about doing it right at the beginning, the rest of the job is easier.