Blog: Fixing Problem and High-Risk Projects
The policy reads, "Before you can proceed, the PMO needs to approve the design gate." So, you begrudgingly wind down the project so the slowest members of the design team can catch up. A week, maybe two, sometimes even more flash by. The rest of the project team starts finding work on other projects. Once the PMO finally gives the project the green light, you will need to wait for people to complete those other tasks before they can focus on your project. Precious time is lost.
Estimates are a pain in the... er... butt. Everyone hates doing them. The reason? They are always wrong. They are either too optimistic, when we think we know more than we do, or they are overly padded, trying to account for the unexpected. Other times it is much more subconscious. Some little voice in the back of our heads is working on our conscience to change the perception of the work required. We can be our own worst enemies when it comes to creating estimates and do even more harm when we go to work the task. For now, let us look at a couple factors that influence how we determine the length of time it takes to do simple tasks and save the effects of that estimate for another article. With a little audience cooperation, we will produce a fun answer from a simple mental exercise.
Last week I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.
The quickest way to get lost, in business or in your personal life, is failing to make decisions. Not knowing where you are headed increases stress and frustration. It would seem natural, then, that teams on projects beleaguered with indecisive management would be excited to have the logjam broken by a dynamic, decisive leader. Simply put, they are not. Every decision has its opponents and they are bound to be irritated, feeling they have lost prestige or stature. However, turning the decision into action requires a unified team. One of the best tools to accomplish this is to understand what impeded decision making and tactfully educating the team members on the source of the problem. This will garner their backing and improve their willingness to support the decision.
In a recent blog on stupid decisions, a reader asked about lessons learned processes. I had to defer the question since my reply would have been as long as the blog he was commenting on. So here we go: the entire class of retrospectives, postmortems, and lessons learned are a waste of time. Well, to be fair, I have never seen them work. They may have worked for others. Maybe the reason I never see them work is that I am involved only on disasters, you know, those projects everyone talks about for years to come, the ones people cannot get way from fast enough. Surely, the type of work I perform taints my experience.
Maintenance does not belong in projects. Combining the two violates the definition of a project, mixes deliverables with opposing triple constraints, and sets the stage for scope creep. Maintenance needs to be performed by a dedicated group that can quickly implement changes. Project teams should focus on completing enhancements that will provide additional value to the customer.
Last Monday Mitch Lieberman invited me to a TweetJam on ITSuccess. My first reaction was, "What the heck is a TweetJam?" Google was of no help. All I could tell was that two of most prominent authorities on IT project failure were at the center of the meeting—Mike Krigsman and Phil Simon. The invitation was an honor. The result was summed up in my closing tweet, "@mjayliebs, that's one of the fastest hours I have spent in my life. Thank you very much for the idea and the invitation." It was one of the most educational and exciting events I have seen in years.
A couple Friday's ago, I was in a meeting and I reiterated my mantra, "Process stifles creativity." A friend, well, I think she still is, nearly jumped out of her chair. "I need to correct you," she barked, "Only poorly implemented process stifle creativity." The suddenness and passion in her response caused the gentleman sitting between us to slide his chair back quickly in order to avoid being tangled in any physical altercation. The room was full of jeers for us to settle the dispute in the parking lot. Realizing I had just stepped in a hornet's nest, I made a joke of it. However, her attack does not dissuade me.
Most projects do not fail for the problems on the project; they fail for the problems in the organizations associated with them. Even issues within the project are usually personnel related requiring the project manager to do more counseling than managing. So where does the project manager get these skills? Unfortunately, they come from experience; few come from formal training. Instead, project managers get training on process, which, as can be seen in many of my articles, is misguided. Project managers need to spend more time developing the organizations, making them stronger. Without doing extensive organization development, projects will continue to fail.
Recently I have seen an abundance of references to decision making in everything from presentations to job titles. Yes, I said job title. Director of Quality Decisions. The second thing that struck me (the first being that it was actually a title) was that it was too low in the company. Are other leadership roles like C-Levels, Presidents, and VPs exempt? Unfortunately, I know little about that job and cannot find the person that got the position. I would love to interview him or her.
Filling Execution Gaps
Available Worldwide |
|||||||||||||||
Filling Execution Gaps is available worldwide. Below are some options.
|
|||||||||||||||
Limited Time Price $20.99 |
|||||||||||||||
Book or Kindle |
|||||||||||||||
Worldwide: Many other book sellers worldwide. |
Rescue The Problem Project
For a signed and personalized copy in the US visit the our eCommerce website.
Book sellers worldwide. |
Other's References
- New PM Articles for the Week of November 9 – 15, The Practicing IT Project Manager, November 9, 2015
- The Argument for Disbanding Your PMO, Accellerated IT Success, Nov 13, 2015
- New PM Articles for the Week of September 28 – October 4, The Practicing IT Project Manager, October 4, 2015
- Episode 332: Project Sponsor Challenges and Solutions, PM Podcast, Cornelius Fichtner, September, 2015
- New PM Articles for the Week of December 1 – 7, The Practicing IT Project Manager, December 7, 2014
- How to buy Project Management Consulting Services: Service as a Product (SaaP), Guerrilla Project Management, Samad Aidane, December 2, 2014
- Episode 275: Your Project Statement of Work is Missing a Comma!, PM Podcast, Cornelius Fichtner, June 14, 2014
- State Invites 10 Firms To Shift Cover Oregon To The Federal Health Insurance Exchange, Oregonian, Portland, Nick Budnick, May 28, 2014
- Decision To Scrap Or Salvage Cover Oregon Health Insurance Exchange Poses Risks Either Way, Oregonian, Nick Budnick, Portland, April 9, 2014
- Cover Oregon Consultant: Fix For Health Insurance Exchange Could Take $40 Million, 21 Months, Oregonian, Nick Budnick, Portland, April 4, 2014
- Episode 205: Rescue The Problem Project, PM Podcast, Cornelius Fichtner, June, 2013
- Episode 206: How to Keep your Project out of Trouble, PM Podcast, Cornelius Fichtner, May, 2013
- How to identify, prevent, and recover from project failure, Accellerated IT Success,April 2, 2013
- Episode 260: The Seven Steps to Rescuing the Problem Project, PM Podcast, Cornelius Fichtner, January. 2014
- New PM Articles for the Week of August 6 – 12, The Practicing IT Project Manager, August 12, 2012
- New PM Articles for the Week of June 11 – 17, The Practicing IT Project Manager, June 17, 2012