Don’t Kill The Golden Goose of Project Management – The Crisis
We certainly would not sell off the fairy-tale Golden Goose to pay for today’s meal. We would find a way to eat today or go hungry and keep the Golden Goose until she laid that next Gold egg. Yet, too often we ignore each project management tool Golden Goose as it comes along.
We were in a crisis. The project was running late, again, just like all our previous projects. We were sure this one was going to be OK. However, it was too late to worry about what really went wrong. Our job was to work hard to get the project back on track — just like everyone else did on those previous projects. We would defer doing anything about what went wrong until the “retrospective” or the “lessons learned” at the end of the project.
We just killed the Golden Goose. When the energy is high and we are well aware of a problem is arguably the best time to initiate a fix to it — to lay the Golden Egg. The Golden Egg is often a small incremental fix to the process but it can also be a big change. For those of us who work on multiple projects, all in different stages of project progress, the fix is often too late for the current project. Those projects still in their early stages, however, are often perfect candidates for improvement.
We had just passed a major early milestone of what was going to be our company’s biggest project. It was the mega-project that would make the company profitable for the next few years. The problem, however, was that we took an existing project, tripled the number of products it was to have, and increased the number of new product features by 450%. And, oh yeah, we reduced the schedule by two months. We all just needed to hunker down and work hard.
As miracles do sometimes happen, a small group of folks decided that we needed to carve out some time and make better sense of how we picked products and when we planned to deliver them throughout the year. The team completed an initial step of identifying the critical months during the year to release new products. Everyone was very satisfied with this result because a huge part of the problem in the current mega-project was we had decided very late when the product needed to be ready. I then spoiled everything.
I too was excited about knowing the yearly delivery dates. I then added that each product not only needed a delivery date, but also an associated kickoff date. I shared with the team the data I had collected over the years on how long it was taking to put out a new product. I then showed what this meant for each delivery month laid out for the year. They pondered my numbers, then decided that the average project durations I offered were too long, and picked shorter durations (Huh? What about all the data? Oh well.). The durations were still longer than what we were using on the now late mega-project. We now knew what a year would look like, when we needed to deliver and when we needed to start. But, there was another problem.
We always had multiple projects going at any one time. They overlap such that while one project (possibly a group of products) is getting started another group is about halfway through the project development cycle. A final group is just about ready to deliver to the customer. The problem? All the projects planned were already late by the solution we just laid out. Every. Single. One. Of. Them. Actually, this should not have been a surprise as this company had a reputation of always delivering their products months late.
For a short period of time a small group of managers got it. We were planning our projects to be late. We were starting them too late for when we wanted to deliver them. I would like to say this changed the organization. It didn’t. At least not immediately. We delivered the mega-project months late. It would take us a few years until we were once again in a position to plan a mega-project with an objective schedule (see Project Management Crisis? Do Nothing!). We finally achieved on-time delivery for that mega-project and also for the vast majority of projects later completed on that baseline.
The Golden Goose of project management is often the crisis. When the crisis hits is arguably the best time to address the root cause that is troubling the project and possibly the company. The crisis is when our energy is at its highest and when our awareness of the problem is at its peak. We may not rescue the current project but newer and future projects can benefit from our crisis — our Golden Goose.
Are you making the best use of each crisis on your project or in your organization?
22 thoughts on “Don’t Kill The Golden Goose of Project Management – The Crisis”
Comments are closed.
Comments from around the web:
Robert Falkowitz | ITSM Consultant & Trainer Sounds very much like a “saving the paradigm” type of activity, especially given that the paradigm, the “project”, has never really been very successful in achieving its goals. Isn’t it time to stop these baroque attempts to fix projects, when the very concept of projects, as a way of changing things, is fundamentally flawed.
Bruce:
Robert, projects work just fine at least in my 30 now 40 years of doing them. However, just like any method, one has to know how to do it well in order to get the results, see the benefits and have the success. Of course, any improvements using other approaches are always interesting and useful and project management today has many differences to how we did it several decades ago.
More comments from around the web:
Dinesh Balasubramaniyan
A very useful article Bruce. A lot of companies do not spend time in doing any type of research especially on managing projects. They think they are a projectised organization, but definitely lack the valuable insights on how to run the projects effectively.
More comments from around the web:
Rick Stockton
Mechanical Concept > Design > Manufacturability
Here is an odd thing. I am hired to design mechanical things. But I often find that some level of project management is vital to maintain the project. I am not hired to do it, and so I have a difficult time charging for it. However, if I do not engage in project management activities, the project can have real problems.
—
Rick,
I got into project management because as a computer programmer I realized that if I didn’t help manage, then things would continually not go well. I believe project management is a core discipline in the technology fields from the trenches to the C-levels. What good is all our work if we can’t pull all the pieces together?
Good comment,
Bruce
More comments from around the web:
Rodney Brim, Ph.D. CEO of Performance Solutions Technology
Executive Coach | Management Software | Delivering ROI with a strategic plan and our software suite | ManagePro.net/blog
Bruce, I think the opening premise is so important. It reminds me of what I’m doing all the time when in the air flying. You’re constantly making course corrections, you don’t wait until you get to the supposed destination or simply add more power. Attentive course correction, especially when you’re feeling behind and everyone is in the space where we don’t have time to stop and look at what’s going on… is uncommon.
More comments from around the web:
Madhvamunirao Sandhyavandanam
Consultant-Management and Marketing
Bruce Benson Sir
Crisis forecasting with failure anticipation analysis derived from ratios of assumptions and expectations; preparing proactive plan of action; is effective tool meeting the requirement of preventive and management of crisis in any endeavor, in particularly project management.
Maja van der Zijden
veranderen zonder gedoe, trekt gestagneerde poging vlot, creëert nieuw samenspel
Sybill do we really learn the hard way? why do we still have so many project managers without overview?
Shakti Dhar Sharma
Solutions for Robotics, AI, Mobile
Crisis can be prevented, by too much planning, a lot of management and slowing things to death.
Or we can move with best tools and vision, be prepared to meet crisis if it comes ( mostly crisis and fear have similar patterns, they don’t happen ) and have a plan to bounce back from crisis. At the very least, learn from it. Avoiding/preventing was always a wrong goal.
Working with startups and entrepreneurs, I couldn’t help noticing the brilliant co-relation.
Thanks Bruce for sharing.
Bob Norton
CEO since 1989. CEO Coach/Advisor/Director. Expert on Biz Acceleration/Growth/Systems. Interim CEO/COO/CTO/CIO.
It is appropriate to consider a “Mode of Management” which varies greatly by the size and maturity of the organization and project.
Many are confused and think the advice or style is consistent and it really varies enormously based on the situation. I have a 5 Stages of Development model showing the maturity and how things vary.
How you act (as a manager, PM or CEO) can be 180 degrees apart at different Stages. The risk you can take, speed, budget and style of managing the team need to be appropriate for that situation. For example a dictatorial syle can work in small projects (start-ups), but collaborative becomes critical in larger ones.
I think the Project Management industry and training programs need to acknowledge this issue and adapt methods to that reality. Few understand this unless they have worked in all size organizations from Fortune 100 to start-up. The same advice and style can be deadly in one and perfect in another.
Planning and goal setting is key. But doing this without taking into account quality of the team, scale and other factors is always a recipe for failure, or at least late delivery and constant management by crisis.
Peter Drucker’s Management By Objective (MBO) process takes these things into account from an organizational and psychological perspective. Nothing here has changed in 50+ years and it will not because people are the same and the major element.
See here for video on the 5 Styles of Management we teach and coach teams and executives to use to achieve higher performance:
http://www.airtightmgt.com/what-is-airtight-management/management-best-practices.html
More comments from around the web:
Bob Norton
CEO since 1989, Business Performance Consultant, Author, Speaker and Creator of AirTight Management
Clients rarely understand the root causes of their problem or crisis. They see symptoms and do not understand the underlying cause, which is usually 2-3 levels deeper. i.e. flat sales is the “problem” in their mind, when poor marketing and sales funnel processes are the root cause. Doing more of what they do rarely provides a solution or gets them out of the “problem”. They would not be in it if they understood this. My approach is to educate and break a project down to address short-term and longer-term problems separately in 2-3 phases. This requires good discovery and selling of the proposed solution. Sometimes companies do not have the cash, patience or time to “do it right” and want a band-aid. I prefer to opt-out of those situations. They are not good clients, as they will cycle through failure repeatedly by never doing it right, then blame you for the failure. Always time/money to do it over, never time/money to do it right. Yes pain and crisis justify the fix it now budget, but smart business people and clients will be willing to address root causes and long-term strategic issues to fix it forever and create competitive advantage that will last years.
Ramdas Chavan
General Manager Technical
in most of the project execution during project execution meeting real root cause for the problem lies at least 1 to 2 level down. Most people capture most seen symtoms and try to resolve the situation and divert focus discussion. this results into problematic situation.
Luiz Nascimento
Senior Managing Partner at AC Comp/DMA Consultores, Lda.
Root analysis capabilities miss sadly from most managers. It should be taught in college, at least a modicum of techniques, with a stress on their importance in real life.
Sybil Dlamini
—
We learn the hard way, prevention of crisis through proper planning , in the first place, is the best.
More comments from around the web:
Allan Rankin
Seeking Operational Assignments
This is John Kotters first step in Leading Change …………..
ELAINE BISHOP
INTERNATIONAL MANAGEMENT CONSULTANT & ENGAGEMENT LEADER
Root causes are sometimes difficult to locate and define. Root causes are often hidden in complexities, changed by dynamism, and influenced by mediating and moderating variables. However, finding and treating root causes and their symptoms is critical.
Rajiv Chopra
@
I agree. Typically, most people search for the most obvious symptoms, and then try and find a quick fix solution. This way they can show “progress”, and often this results in more problems and more complexity later on
Paul Forsythe
Business advice & training : Creative thinking, problem solving, product development
At the heart of this story is an overloaded team with unrealistic schedules. Project managers are used to serious under-estimates of time and even more familiar with the safety margins that are added and multiplied. If the start and stop times of the different tasks are based on these estimates, it will be next to impossible to identify the true critical path
I’m not too surprised that the real data was viewed as something that could be improved on – taking the shortest times as the target rather than the realistic longer-than-average.
I’m trying to digest Robert Newbold’s book “Project management in the fast lane” that applies the Theory of constraints to the subject. The basic principle involves working with realistic, not padded estimates for tasks and building in buffers at appropriate points in the critical chain (not path) to deal with fluctuations and delays
More comments from around the web:
Aleksander Sosnowski, MBA, CSCP
Logistics Director at WABCO
Design to failure on one side and act of agility on the other. Life. It’s simple – you just need to manage it 🙂
John Gilger
Sales sagging? Leadership lacking? I can fix that — Marketing Consultant & Copywriter
Good article. Too often we forget that “there is cash in chaos” whether it is more work (and fees) for the consultant or improved processes for the client.
Rajiv Chopra
There is lots of cash in chaos. I think that chaos can also help a person become more inventive
Waltraud Gehrig
Each crisis bears a chance and can be solved!
A well written article! I can only agree. In my experience almost each project comes to a ‘critical’ point or in worst (or best cases?) to a crisis. The worst thing then is a stand-still, which is unfortunately often the case. It always requires the right people to identify the crisis and accept it as such, the right people to give the ‘go’ to manage the crisis and last but not least those who find the way out and collect the ‘eggs’ in the end. But in the end a crisis bears a lot of chances and positive outcomes for almost everybody involved.
Maja van der Zijden
een nieuw perspectief met verander kunst als kompas, met als resultaat nieuwe wegen voor een andere toekomst
i like you comment Waltraud. And I think we have to think the project more through before we start
Christine Walsh
Supply Chain Development Manager at EBLEX
As they say Pain drives change. It is only when companies experience that “normal” is not producing results they decide they need to find new solutions. Strike while the iron’s hot.
Tim Meuret
Independent Consultant at Transworld Systems
There is one danger in creating a solution under pressure. People often will jump to conclusion and not follow all the steps required in good problem solving. This said I agree with the article and the comments above.
Joyce Stoer Cordi
Versatile,Practical Management Consultant
Independent Consultant —
A crisis is a precipitating event that demands change — when a known problem moves from chronic to acute —
The seeds of the solution are already present and the best consultant makes a hero of management that hired him/her by building a solution quickly that embraces those seeds and fertilizing them with new ideas and new tools —
Too much change in the midst of a crisis creates paralyzing anxiety —
Ending the crisis is not the end of the project plan — but just the end of phase one
Waltraud Gehrig
Each crisis bears a chance and can be solved!
Tim, I completely, agree with you. In my experience thorough and deep analysis needs to be done to exclude as many unknown factor as possible. And yes, that takes time.
And I completely agree with Joyce about the anxiety factor. Here the person managing a crisis should have at least a certain level of empathy. Change is a curse and a blessing at the same time and everybody reacts on that differently. Everybody involved in the crisis is an individual with an ‘own history’. And this plays the same role in a crisis like organisational stakeholders and other factors.
Last but not least I think, in each crisis management transparency in communication to a maximum possible extent with all parties involved is required to keep the level of resistance for change on a low level and get everybody on board for the change.
More comments from around the web:
Bruce – The excerpt above & the article make the case for the value of Lessons Learned as part of the performance Cost, Effort & Duration estimates for all WBS elements. Although I get a lot of negativity about EVM, there is no substitute for timely identification / reporting of variances, accurate (i.e., honest) root cause analysis & effective corrective action.
By Ted Gaughan
Reply from Bruce:
Ted,
I love a good technique, but my experience (in government and in the corporate world) is that too often the selected technique is overkill for the problems being encountered (examples: http://pmtoolsthatwork.com/project-management-on-steroids-kick-the-habit/ ). Once we did nothing more than get our proposed schedules closer to the ultimately real ballpark (hey, why do you need so much time?!) and started to deliver projects on time, then an awful lot of the mandated techniques no longer made any sense nor did they add value (nor did they add value during distressed projects for that matter).
With that said, I’ve seen and used a lot of methods (and discarded a lot) and what counts is what works in our current project environment.
Thanks for the comment,
Bruce
Comments from around the web:
David Wheeler
Owner, Mitec
As far as I am concerned, it’s thinking like this that drives a bad name for all good Project Managers who strive to deliver effective and low impact projects.
Reply from Bruce:
David,
Good point. I suppose this could be interpreted as being a bad habit.
For project oriented organizations who struggle regularly and have a hard time ever delivering projects on time with good quality, then these in particular need a method to help improve an organization.
As the article highlighted, one such organization did exactly that — focused on the problem as it happened — and it resulted in a rather astounding insight that we later leveraged to get all our projects to deliver on time.
Thanks for the feedback,
Bruce
Any chance you can turn this into a Case Study Webinar for the PMI-MN Chapter?
Kimberly,
I’m open to making Don’t Kill The Golden Goose of Project Management a webinar case study for your chapter. Let me know how you would like to go about it and when you meet.
Regards,
Bruce
Brett,
On successful corrective actions:
http://pmtoolsthatwork.com/seven-ways-to-make-that-silver-bullet-work/
Bruce
Good points
Obviously, the objective is to take corrective action to prevent the SAME old problems from recurring, however you do it. Of course, the real problem is getting people to do it. 🙂
I would be VERY interested in success stories on getting this corrective action to actually take place, and how they made it happen.
Brett,
I’d prefer not to have post project reviews, simply because they are almost always too late, we forget so much, and we are now focused on the next thing, and not interested in talking about the past.
That is why improving the process and fixing the problems needs to be done as it happens. Agile Scrum has a retrospective but it is after each sprint (which is 2-4 weeks) so this is a good compromise (at least in terms of timing).
One nice and unexpected benefit that comes from getting schedules right (good estimating) is that it just about always enables improvement efforts to happen while we are doing the work. When we fixed the schedules for organizations who are perpetually late – their quality improved dramatically and one reason for that is they can take the time to do it right – and that often means taking some time to fix existing problems and improve existing processes rather than continuing to work around them.
I’ve seen one great lessons learned document from a completed project. It was so good, had such good data and good suggestions, that it became my plan for how I did my project. I’ve only seen one (1) truly good output from a post-project review in over 30 years of digging through these kind of things.
Let me add that I don’t mind the post project review, only when we use it as an excuse to defer fixing anything until then.
Boy can I relate to this article. LOL
If you can’t address the problem immediately, at least make a quick note in a log of what went well and what didn’t. Then, HOPEFULLY, I know its rare, you’ll have a post project review. Never try to remember EVERYTHING that went well and didn’t after the project. For a project of any length, you won’t. No, you won’t, unless you have a photographic memory.
As Bruce noted, unfortunately, MOST companies aren’t interested in addressing or fixing the cause of a problem. They keep making the same mistakes, and usually the people in trenches suffer the most. The attitude is, again unfortunately, nature of the beast. Like it or leave it. Especially in this economy, there are plenty of replacements available.
How do you get companies to buy into post-project reviews and process improvement? Great question. I’m all ears, or eyes in this case. 🙂