Tip of The Week: Start your Project on the Right Foot… Do NOT start with an End Date!
Of all the project pain points that can be experienced, starting with an End Date before scoping and properly estimating, can arguably be ranked number 1. This scenario often happens in order to get project funding approval on an “if only it can be accomplished by “X” date”. There may be solid reasoning for placing the end date first on the schedule, such as a government mandate, but this does not make it an acceptable practice for all projects.
Backing into the date can create project toxicity from the start and increases project risk exponentially. Although it may be intimidating, if you determine that the project cannot be completed by the imposed End Date it needs to be communicated with supporting documentation as early as possible and also recorded on your project’s plan and risk register.
You may also provide alternatives to meet the date, such as a phased project approach. Deliver a manageable portion of the project by the proposed End Date, with subsequent phase following until full project scope is met.
What to do with a Creep in the Room!
The term Scope Creep is commonly used to identify any change that was not within the original project scope. Keep in mind that this not necessarily a bad thing. Projects by nature are dynamic, and change is typically unavoidable. I’ve had project sponsors say, “There will be no change requests on this project!” They were obviously concerned about the project’s budget and timeline, but it is unrealistic to say that there will be no change on a project. It is important to make the sponsor and project team understand that scope changes/creep can occur due to numerous reasons regardless of the team’s experience, planning, and foresight. To remove the stigma, after project kick-off, document and present a change that does not affect the project scope, timeline, resources, or budget.
With this said there are other types of project creep that are real problems; Hope, Effort, and Feature Creep.
I recently had a fire at my house. A high voltage wire in the electrical meter box on the outside of the house exploded and caught fire. The good news we were home, the fire was quickly contained, and thankfully nobody was hurt. It was obviously unexpected and not on my radar as a risk. This had me thinking a bit about how “fires” appear unexpectedly in projects. As Project Managers we plan for the expected and also inherently face the “known-unknown”; knowing that unexpected events, circumstances, or outcomes will take place in our projects that are hard or even impossible to plan for or predict. These unknowns could be small changes in scope or even loss project funding.
The HBO hit series, Silicon Valley, is nearing the end of another great year. If you have not had a chance to watch, do not worry; there are no spoilers ahead. If you are unfamiliar with the show, it is an entertaining story about a quirky group of developers with a great software idea; and we follow their journey through funding, development, and marketing, while dealing with a multitude of project challenges, pitfalls, and successes. Season three begins with a true project leadership challenge; how to get the project team to buy-in and move in the same direction with a shared vision.
While in the show, there is a power struggle that becomes the catalyst to the project team continuously shifting their project’s direction; it had me reflecting on my project experience and a few simple steps I’ve learned to create team alignment and project buy-in:
I did a Google search on “Project Managers are” and was surprised with what Google revealed as autosuggestions:
Top results are: Idiots, Responsible for, Useless, and Stupid! Three out of the four are pretty cynical to put it mildly. I certainly do not want to be generalized into these negative buckets and I’d bet nether do you! Here are some qualities a good PM should possess that will help change these stereotypes.
After spending the better part of a decade managing projects for large Fortune500 organizations. I recently had the opportunity to consult and project manage for some small companies. As you would expect that there are positives and negatives in both, and the disparity can generally be seen with team size/support and decision processes.
Networking is often thought as a ‘pre or post’ by-product of attending a PMI dinner, lecture, or a business meeting. Often we skip the networking portion because we are in a hurry to get home. Instead it is important to be able to dedicate the time to improve our professional relationships, learn from our PM peers project experiences (both good and bad), and discover if there are new techniques that could be applied to your own projects.
We are in the final week until the regular season the National Hockey League comes to a conclusion. Teams are fighting for playoff positions, but our attention is drawn to not the top of the standings but to the bottom. The “race” to 30th place has caused a lot of discussion on sports talk radio and national publications. Sharp focus is on the current last place team, the Buffalo Sabres. Fans are divided on whether the team should deliberately try to loose games, in order to get a chance at the number one draft pick, or at worst the number two draft pick (per the NHL’s draft lottery rules). As a project manager, I took a broader look at this event in Sabres history, as the fan opinions steadily grow apart. Although sports fans will always have varying opinions, what has been missing is a solid project Stakeholder Communication Plan.
If you surveyed your project team and asked them what your project is going to actually deliver, what would the answer be and would it be the same for everyone? You may hear a lot of 30,000’ level general answers about creating more value for the business or customer base, or whatever they think the project sponsor wants to hear. In actuality, your team should be on the same page and be able to clearly define the tangible product of the team’s hard work. If they do not, then they have either not read the Project Scope Statement, or the Project Manager has not reviewed it with the team, or the Scope Statement does not exist at all!
The Scope Statement is one of the most important documents that the Project Manager has in their tool belt. It clearly states everything that the project team will deliver. So if it isn’t on the Scope Statement your team should not focus any effort on it! Pretty cut and dry, right?! Not so fast, good scope management through out the project is necessary, because scope creep is always lurking nearby (see my blog on the types of creeps <here>). The good news is that with solid project documentation and communication, scope management does not have to be difficult.
Here are some simple steps to Scope Statements and Control:
1 – Prepare Scope Statement
- The overall defined description of project scope
- A comprehensive list of what is included in the project
- A list of what is specifically excluded (out of scope) from the project
- Clearly defined acceptance criteria for each scope item
- Any constraints and assumptions that relate to scope items and/or how these are to be delivered
2 – Scope Control
- Keep on top of any and all change discussions, rumors, and hallway banter that you may hear. It is easy for these to be escalated, and before you know it, your sponsor or customer may be expecting some new project deliverables with out you knowing it.
- Use a formal Change Control process for all changes no matter the size or impact on budget, time, resources, etc.
3 – Verify Scope Throughout
- As deliverables are completed, get them approved by your own team and then verified by the sponsor/customer as well. By doing this you will be sure that the team is on target with project scope and expectations.
A Project Manager does not necessarily have the luxury of picking their project sponsor. At times the cards are dealt and you have to deal with a difficult sponsor or team.
Throughout my years as a project professional, I could name plenty of examples of “difficult sponsors”, such as; being indecisive, changing project timelines, changing the scope, avoiding responsibility (e.g., not making/delaying key decisions), unrealistic expectations, not providing the right resources… the list could go on!
So, what’s the best way to handle your difficult sponsor? From day one, build a strong partnership with the sponsor! Being honest with your stakeholders is the fist step in building the trust and credibility that will make difficult conversations a bit easier. I have learned this lesson the hard way, as I was transitioned to a few projects that had been started by other PM’s. Those PM’s, once confronted with a difficult sponsor, cowered in fear of upsetting them. They would say “yes” to everything, essentially conforming to their customer’s indecisiveness. By doing this it builds a false foundation for the project and the team, and sets it up for failure from the start.