Do management plans add value or do they just waste time?
You’ve been tagged as an expert in project management by your customer and team. There is a requirement to develop a series of management plans under the construct of a program. Someone taps your shoulder and says you have been volunteered to produce one or more management plans.
What is the first thing that comes to your mind? “Oh man! You mean I need to write a document that nobody will read nor use. What a waste of time.”
The answer to the question depends on your perspective. Developing management plans should be viewed as an opportunity. This is an opportunity to further your understanding of a subject area which allows you to grow as an individual. The management plan becomes a recorded of your understanding and furthers the opportunity to enhance the body of knowledge of your program and projects. The processes begin to mature which potentially saves time, money, and unnecessary frustration.
It is a real challenge writing a management plan. First finding the time to apply yourself, second finding a quiet place where nobody can find you, and finally reengaging your brain to think critically. As your research you discover standards, best practices, and guidelines offered by industry such as:
- PMI’s The Standard for Program Management
- PMI’s PMBOK
- DI-MGMT-81334B
- MIL-STD-881
- INCOSE SE Handbook
- ANSI
The trick to developing a managment plan is finding the right blend of industry best practices within a framework that flows consistently across all managment plans that can be applied to the program and projects. The real test of a managment plan is to answer the question, “Can I do this (scope, risk, time, etc.) with no further definition?”
What is your perspective on management plans? Have you written a program/project management plans? Share your experiences regarding management plans.
Management plans can be valuable, but in my experience usually not.
IMO, starting with standards is a mistake. The starting point should be the reality of “how things get done around here.” That’s not going to be easy – usually there are many processes which are not well defined in any organization, and half your time will be spent interviewing people who actually do this stuff on a day-to-day basis and consensus-building for those processes which are not well defined and/or have contention among staff on the best method.
Seldom is there no organizational or project history to draw on; If this isn’t your first project in a start-up company you can start by mapping reality.
When you start with standards:
– The plan is great in theory, but not in practice (reminds me of a Yogi Berra quote)
– The plan doesn’t resemble how things actually get done, and so lacks credibility with staff
– The plan employs a lot of fancy language and references to standards no one understands but the author, adding to the probability it will not be read or followed
When you start with reality:
– You facilitate the writing, but the primary source is the stakeholders of the processes ( = buy in! )
– You gain a deep understanding of how things actually work in the current state – this deep knowledge of the domain is the only way to write a credible plan
– You start with a credible and accurate plan, and can iterate from there – knowledge of the standards out there can now be useful…it’s only useful if you’ve gained the deep knowledge of the processes in your specific context
Furthermore:
– A plan without majority input from the staff who will carry it out is doomed to failure
– Attempts to change and dictate new processes in a document are doomed to failure; that’s doing it backwards. Unfortunately that’s exactly what most organizations do, especially in government in my experience. First, gain understanding and build consensus through conversation, drafting visuals of processes, etc. Then document it as concisely and clearly as possible. Changes follow the same process – 1) understanding – 2) discussion/drafting – 3) document.
Second, I disagree with this statement:
Using that goal as a way to gauge value will lead to long documents, 80% of which are processes seldom or never used, and which will never be read by practitioners.
It’s the 80/20 rule in full effect.
Using what I said in my last comment, after deep domain knowledge of the processes in use is gained, you’ll know what the most critical processes are, and which scenarios happen most of the time.
Don’t bother trying to account for every possible scenario. It’s muda (waste) in my opinion.
Guidelines from my perspective:
– Must be less than 10 pages in length
– Must be primarily visual with supporting text, not the other way around
– Highest Effective Level of Detail – in the weeds is not where you want to be, document at the highest level possible that still gives appropriate guidance and answers the right questions for actual users of the process.
– Don’t assume the users of processes are nincompoops – I’ve seen too many plans like this – assuming people won’t know how to tie their shoes unless they reference the plan is a good way to make it unusable and even insulting – users are smart in general
I think that a plan based in the reality of the organization is essential. Most agencies don’t work like someone’s off-the-shelf model of how an org can work. In a hierarchy, the higher-ups usually come up with a plan based on their perception of the organization, which may or may not bear any resemblance to what the staff experiences.Most project managers I’ve experienced expect the project to work like their favorite model, regardless of agency culture.
I’ve seen too many cases where the management plan works until it impinges on someone’s personal fiefdom, and then it falls apart. for whatever reason, the fiefdom doesn’t get overthrown, but there is suddenly a huge roadblock in the way.
The bigger the organization, the harder it is to change the culture, but that has to happen first. Maybe management plan needs to happen from the bottom up: Make a clear objective and then let the folks down the food chain develop the plan.
If you are writing the plan to satisfy the requirement to have a plan — it will add no value.
If you are writing a plan to guide the project to the end result then it can have value.
If it is a poor plan, written in a vaccuum, based on unrealistic assumptions and overly optimistic progress estimates, etc, then it is only slightly better than no plan.
If you write a good plan, then you have to actually put it to use to guide the project. An old military saying seems pertinent “no plan survives first contact with the enemy” — expect to adjust the plan as conditions change, then it will continue to add value. If you don’t adjust, then it will lose value.
One other cautionary note, again from a military perspective — don’t spend all your time & effort to make a perfect plan, but do make a good plan and then act. As Gen Patton said “A good plan, violently executed now, is better than a perfect plan next week.”
@Kevin, this is perfect “Make a clear objective and then let the folks down the food chain develop the plan.” – or certainly, the content for the plan should be coming from interviews with the people who actually do the work.
Thanks @Scott – that’s another key point…..it seems like many times management plans are assumed to have a very waterfall-ish nature…spend lots of time in analysis and writing the perfect plan, and then never touch it again or do scheduled annual refreshes.
If you have to schedule refreshes, your plan is not being used. And you should expect to iterate it often, especially after it’s first been written. Needs change over time and any plan should change with those needs.
Having a build any time of plan is a great time to collaborate with those that have a stake in the outcome–particularly if they have to do the work. The real value is not the document produced by the effort. The real value is in the shared understanding that develops among the planning team members. Or as Eisenhower, Mintzberg, and others have said, the real value is in planning, not the plan.
Thanks everybody for leaving your comments. I do agree that good plans are developed from the bottom up. Tapping into the people actually performing the work as the source really adds value. Also noted below, document plans are about the journey of learning and then sharing that lesson with the rest of the project team. Final, plans should not be written and then put on a shelf. The plans should be a living document that is maintained as new aspects come to light.
Again thanks for your feedback. It really helps.