Ron Rosenhead provides a great post about the organizational sources of project failure.
There are of course other sources of organizational failure modes, but Ron's list is a great starting point.
Ron Rosenhead provides a great post about the organizational sources of project failure.
There are of course other sources of organizational failure modes, but Ron's list is a great starting point.
Posted by Glen B. Alleman on November 07, 2009 at 07:00 AM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
The processes needed to increase the probability of a project's success include:
Posted by Glen B. Alleman on October 21, 2009 at 11:45 AM in Project Management | Permalink | Comments (1) | TrackBack (0)
|
Posted by Glen B. Alleman on October 14, 2009 at 07:02 PM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
There's one of those unqualified, unsubstantiated, and pretty much curmudgeon quotes floating around. You know the kind. "It didn't work for me so it can't work for you." It usually goes like this…
"I think it is clear that matrix management is not and does not work, leading me to conclude that it is one of the LEADING CAUSES for the rather abysmal "success" rate of projects in most organizations."
Of course, there are no units of measure here. No technical, business, or operational context or domain. No actual evidence or facts, other than personal opinion and anecdotes – a dangerous approach to process improvement.
So let's see if we can get all this anecdotal "theory" about matrix management to somehow come in contact with reality.
In the manned space flight business and nearly every other DoD, NASA, and DOE domain matrix management is the basis of Integrated Product (Project) Teams (IPTs). See O 413.3-18 as an example for the DOE context. NAVAIR and NASA have similar practice guidance.
http://www.directives.doe.gov/pdfs/doe/doetext/neword/413/g4133-18.pdf
So here's how it works. Let's pretend I'm the Propulsion Engineering Lead (yes it is rocket science).
I'm accountable for the design and development of the propulsion systems for our flying machine. This is critical concept - accountability - that is missed in most programs that go into the ditch. First Accountable, then Responsible. See http://herdingcats.typepad.com/my_weblog/2007/02/responsibility_.html for discussion on the RAM.
I report to the Program Manager - single line of responsibility flows down. But it flows down through the Systems Engineering Lead. I take direction from two people. The PM and the SE. They work with me in a matrixed manner since we're on an IPT organization. Now if they tell me conflicting things - say how much thrust is needed to hold orbit at Mars, then I need to convene a meeting to get this sorted out. Why, because I'm ACCOUNTABLE to make the propulsion system work. It doesn't work, the mission fails.
Now, the PM has bigger role than the SE's. So during the meeting, the SE's will make their points, I'll make my point (all supported by technical data, no opinions allowed here) and the PM will take all this information in and we – as a team - will have CONCURRENCE on the outcome. Remember we're an IPT.
Now, in walks the Safety and Mission Assurance (S&MA) Lead, http://www.hq.nasa.gov/office/codeq/ . And she disagrees with our little decision. So who trumps whom? Well in the manned space flight business S&MA has a powerful role. More powerful than the PM, because certifying launch readiness is a S&MA role, not a PM role. We're back to accountability.
All these accountabilities are defined in the Responsibility Assignment Matrix (RAM). The responsibility, accountability, communication, information (RACI) model drives how the IPTs work inside the matrix. In fact the responsibility part of the RACI is never addressed until the Accountability assignments are made, and then it's up to the accountable person to flow down the responsibilities.
So to attempt to get the theory to come in contact with the reality of how matrix management "can" work. Because that's what real PM is about, the realities of projects.
No doubt there are numerous examples of how to make it NOT work. But that's called a "false premise" argument. Just because you've never seen it work, or have some quotes from a couple of dead guys who say it can't work, doesn't mean it's not working every day on 1,000's of programs. It's proof by anecdote. NOT
It's critical here to look around for places matrix management does work and see if what they do is in anyway useful and applicable to your project environment. Maybe it's not. But that doesn't mean it is generally the case that it doesn't work. In fact just the opposite. If it works someplace else, you have an anecdotal working example. Try and figure out how they made it work. If you can't figure it out, or can't put to work what they figured out – we've found the problem – YOU. Learn from others, don't belief everything you read in 50 year old books. Ask deeper questions. Investigate multiple views. Try to determine if a concept or statement is in fact universal, or just an anecdote of failure in a specific domain.
This is a common mistake of inverting the search for improvement. "Doesn't work for me, can't work for you," is a weak approach to trying to increase the probability of program success.
Posted by Glen B. Alleman on October 14, 2009 at 11:48 AM in Project Management | Permalink | Comments (7) | TrackBack (0)
|
The Project Management 2.0 has yet to state how project's are improved in units of measure of the beneficial outcome. Oh there's some time savings in communications of the project team. Lot's of marketing hype. Hype 2.0 is a popular term applied to most 2.0 initiatives.
How does any process improvement effort actual show that processes are improved? In the absence of tangible evidence of how a project will be improved any 2.0 effort degrades into buzz words.
Not Buzz Word Words
What's missing from project's? Project Management 2.0 needs to define in units of measure meaningful to the customer (most PM 2.0 messages are product sales messages) and say how PM 2.0 provides the mechanism to:
The PM 2.0 solution needs to be actionable beyond buying a product.
PM 2.0 needs to:
Posted by Glen B. Alleman on October 07, 2009 at 08:41 AM in Project Management | Permalink | Comments (2) | TrackBack (0)
|
Michiko Diby referenced a GAO (Government Accountability Office) report titled Business Process Reengineering Assessment Guide. This report, written in 1997 rings true today for any re-engineering for for that matter any IT enterprise project.
A quick (generic) summary
Assessing the decision to pursue a process improvement project
Assessing the improved process' development
Assessing the project implementation and the results
Posted by Glen B. Alleman on October 03, 2009 at 03:56 PM in Project Management | Permalink | Comments (3) | TrackBack (0)
|
Paul Ritchie introduced a new idea – the Black Letter Law. This is the notion that there are basic standards for any practice. The original practice for Black Letter Law was of course Law.
So are there Black Letter Law’s for Project Management? Paul mentions three. Here’s my take on expanding Paul’s great concept.
Now why is this important?
When someone comes along and claims to have something new. Be it PM 2.0, agile PM, some clever tool, or even a new take on a way of actually managing a project instead of trying to sell us something that can be used to manage projects – this is a way to ask some simple questions.
The answers to these and any other questions must be in units of measure meaningful to the buyer. No fluff. No “we’re the best thing since sliced bread,” no “everyone gives us wonderful reviews and votes us the best gadget in the valley,” no "here's a bunch of people who spent money with us, so you shoudl spend money with us as well."
Nope, the answers to these questions have to describe the unassailable beneficial outcomes. Stated in units of measure meaningful to the buyer. These units of measure should be dollars saved, risks reduced, value increased. Never can they be "we increase value." How much value - tell me the actual amount or at least a relative percentage. "We save you time." How much time?
Don’t hear that message? Move away away folks, nothing to see here.
Posted by Glen B. Alleman on October 02, 2009 at 05:30 PM in Project Management | Permalink | Comments (2) | TrackBack (0)
|
The Deputy Secretary of Defense Gordan England has a simple foundation for how to "make" a leader:
Posted by Glen B. Alleman on October 02, 2009 at 07:00 AM in Project Management | Permalink | Comments (2) | TrackBack (0)
|
The US DoD has started using an "Eight Step Process" for logistics and other activities. These are (in general terms)
The source of these steps is rooted in the OODA Loop (Observe, Orient, Decide, Ac t), which originated in the 1950's by Col. John Boyd. It is an objective description of the decision making process. Due to an emphasis on the infinitely repeating nature of decision making, the OODA Loop is an excellent match for the AFSO21 (Air Force Smart Operations for the 12st Century) principal of continuous improvement.
In the project management context and domain, the Eight Step Process works like this
Posted by Glen B. Alleman on October 01, 2009 at 07:00 AM in Project Management | Permalink | Comments (3) | TrackBack (0)
|
Dmitri Ivanenko has some good things to say about status reports in "Are You Ready for your Next Status Report?"
One critical missing piece in this post the raw materials for the status report come from the plan. You plan the work and work the plan, you have the materials for the status report in your plan. This "plan the work and work the plan," is independent of any product development method. Agile has plans. They're called planning sessions. Agile works the plan, it's called an iteration. DoD has a plan, it's called an Integrated Master Plan / Integrated Master Schedule (IMP/IMS). DoD works the plan, with weekly Work Package assignments and Earned Value reporting. So no credible project can not - not plan the work and work the plan.
But the status report still needs to report status of the planned work:
What a status report does is
Report the status of the planned activities. So have a credible plan and report progress against it using Dmitri's guidance.
Posted by Glen B. Alleman on September 27, 2009 at 08:52 AM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
Pat Weaver provides more insight on the issues of Project Management 2. I had not seen Wikipedia article he references. In it Traditional Project Manage is described as:
Wow. I didn't know traditional project management operated in this way! Now of course the number one author in the references list at the bottom of the Wikipedia page is selling a PM 2.0 tool based on this premise.
This list, repeated in other blogs and web sights about PM 1.0 attributes is actually a description of incompetent business management, ignorant personnel management, and malicious use of position. You know businesses that are going out of business.
Pat goes on in his post about the reasonableness of the PM 2.0 content of the Wikipedia article. Pat has restated many of the same points I've made and Quant.M.Leap made. My sense is the authors of the PM 2.0 approach defined in the Wikipedia track have somehow concluded all the world are fools and only they have the answer. Yes, ERP projects fail in many ways at an alarming rate in the press.
Of course these PM 2.0 advocates probably haven't actually managed ERP projects or seen successful ones to know the difference between the attributes of success and failure. Nor is it likely they can know the difference between the Boston Big Dig failure and the successful I-25 corridor here in Denver.
It's actually irrelevant in the end
Thank the stars above, no pubic institution or credible private enterprise is going to buy their message "as is" for a simple reason - governance.
Business and project governance. Governance of course does not assure project success. But governance assures that the nonsensical descriptions provided in the Wikipedia Traditional Project Management attributes do not exist in principle. Governance makes every attempt to also assure they do not exist in practice.
So Here's My Simple Minded Conclusion
PM 2.0 will go the way of the first round of "wanna be" extreme programming advocates. Note I did not use eXterme Programming, because Ron had and still has one of the viable alternatives to the "design, code, test" approach of the past - along with Scrum, Crystal, and DSDM. What the extreme programming advocates - those who read the book, but never did the work - wanted was to eliminate all the prep work needed to get in a position where eXterme Programming could work.
The great thing about approach taken my the misinformed, ill trained and inexperienced extreme advocates was they never got hired by any outside firms to practice their voodoo. Same will happen here.
As pat suggests
Beware zealots bearing gifts
Posted by Glen B. Alleman on September 27, 2009 at 08:34 AM in Project Management | Permalink | Comments (6) | TrackBack (0)
|
Here's another attempt to put some structure into what some authors are calling PM 2.0
I'll start with a simple list of what activities take place during a project. PMI calls these Knowledge Areas. This means knowledge of "what" to do is needed to increase the probability of success of the project.I'm not the biggest fan of PMI, but I am a member and the Knowledge Areas are a good starting point for shared vocabulary.
I've learned that without a shared vocabulary the conversation is hard to have. So here's PMI's simple vocabulary about what happens during a project. These are not product development verbs, they are project management verbs.
With this stating point - it's a starting point, but I can't think of a simpler one for this post - what are the activities performed which managing a project in the Traditional, Agile, and PM 2.0 paradigms.By activities I mean, what does the project manager and the technical teams do while working the project that is independent of the engineering processes - writing code, welding metal, pouring concrete.
Several colleagues and I have tried to make a run at this. The topic of "what is project management" outside of the PMI paradigm has been talked about before. Here's my rough cut for the traditional processes.
Posted by Glen B. Alleman on September 22, 2009 at 11:54 AM in Project Management | Permalink | Comments (5) | TrackBack (0)
|
People, Process, and Technology is a common management consultant set of "pitches."
I'm here to say it's in that order. And the order steps done in logarithmic. Meaning Processes is e (2.71821) less than People. And Technology is 2.71821 less than Process.
This put process 7.29 less than the people.
Want to find the way to increase the probability of a project's success - It's not the tools it's the people.
Posted by Glen B. Alleman on September 20, 2009 at 07:27 PM in Project Management | Permalink | Comments (2) | TrackBack (0)
|
The US Department of Energy has $1.2B allocated for clean energy initiatives. Our firm is working a program that captures carbon from coal fired power plants and uses it to feed an algae farm that in turn makes a refineable "oil" (lipid) that can be burned in vehicles or turbines.
Along the way, we are building a Project Management Plan. The DOE has some useful guidelines for what makes a credible project plan.
Posted by Glen B. Alleman on September 16, 2009 at 11:31 AM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
Thanks to Ron Rosenberg for another useful post about the failure modes of projects. The Lecture can be found HERE
Continue reading "Project Failure Sins and How to Stop These Sins" »
Posted by Glen B. Alleman on September 07, 2009 at 09:14 PM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
- No searching through your notes.
- No making things up
- No trying to convince people your idea is better in the absence of actual field experience and testimony that it is in fact better
- Understand - in depth - the context and domain of any topic of discussion before provided suggested alternatives
- What does done look like?
- How will we recognize done when we see it?
- Speak with nouns and verbs about the deliverable and its maturity - "The Preliminary Design of the Transaction Processing System is Complete"
- These units are always time and money
- We'll be done on or before this time with this confidence
- It will cost this much or less with this confidence
- First have a plan that shows when you will have tangible evidence of progress
- This evidence must be a "working" thing that the customer will recognize as something they asked you to build. It can be software, a piece of hardware, or even a document.
- This evidence must be compared against the quality standards agreed to before the work started.
- Again this is one of the "what does done look like" questions
- Earned Value is the best
Posted by Glen B. Alleman on September 02, 2009 at 06:21 PM in Project Management | Permalink | Comments (4) | TrackBack (0)
|
The customer bought a product or service. Actually the customer bought a capability. No if fact the customer should have bought an "effect," a change in the current way of doing business, executing the mission, or some other means of changing from the "now" to the "future."
What does this "effect" look like. What capabilities must be possessed to create this effect. That's what done looks like.
Plan the work that moves the project forward. This work must produce a product, a service, or some processes that supports the production of a product or service. Anything else is waste.
Weeks are good, days are really good, never more than a month should pass before tangible physical evidence is examined.
If you're not measuring physical percent complete, your project is Level of Effort - Train Watching. If you're not measuring outcomes and the quality of those outcomes - not output, outcomes - then you're a level of effort project.
A Plan is a strategy for success. Have this plan before you start the project. Without a plan, you will loose sight of what done looks at the first sign of difficulty.
This is a core concept of Covey - Begin with the end in mind. If you don't know what "done" looks like, you'll never be able to recognize it when it arrives.
If you don't have a risk management plan, your risks will become issues and then it'll be too late to do anything about them
It Is This Simple
Posted by Glen B. Alleman on August 30, 2009 at 05:29 PM in Project Management | Permalink | Comments (0) | TrackBack (0)
|
PMBOK speaks about quantitative risk analysis in Chapter 11. There are several issues with this section of PMBOK that I'll present below. But first, why is this is interest to me and potentially of interest to others?
Opportunities are NOT Positive Risks
PMBOK states in 11.5.2.1.2 that positive risks are opportunities. Harry Jabagchourian and Robert Cvetko of The Boeing Company, Rocketdyne Propulsion & Power, Canoga Park, California have something to say about this in Risk & Opportunity Management: Program & Project Management Success Factors, Fourth National Symposium on Space System Risk Management. This paper provides a introductory overview to the issues of managing both risk and opportunity.
Here Risk and Opportunity are defined - not as opposites - but as two independent domains that must be managed concurrently.
PERT and Probabilistic Risk Management
Like a previous posting, the use of the PERT formula (a+4B+c)/6 is both naive and likely produces wrong results for any non-trivial network schedule. The primary issues with the PERT formula are:
So What's the Way Out?
The current "best practice" in the defense and space domain is a Monte Carlo simulation of the Integrated Master Schedule. But this IMS must start with being credible. This means:
With a credible schedule, the statistics of the task variances must be build. The classification of risk is the best way to do this. DO NOT ask people what the pessimistic or optimistic values are. There is a large body of research showing this produces a highly biased result. Instead build a matrix of risk ranges and their descriptions.
For example:
These classification are needed for each major category of development - software, hardware, integration, etc. The use a Monte Carlo tool (Risk+ and @Risk for project are my favorites).
The result is a credible model of the variances and programmatic risk areas for the schedule.Use these to mange the project, engage in conversations about the "hot spots" in the schedule and how you're going to "cool down these hot spots." The simulation is not the solution, it simply points to where solutions are needed.
Posted by Glen B. Alleman on August 21, 2009 at 09:49 AM in Project Management | Permalink | Comments (4) | TrackBack (0)
|
Here's a check list for increasing the probability of success for you project. This list should be considered EXHAUSTIVE in terms of the traditional Program Planning and Controls paradigm. But not universally applicable for the simple reason that all projects are not the same. But in general some form of these activities should be found on any non-trivial project no matter the method used to manage the project or the method used to develop the products that result from the project.
The source of this check list is the San Diego Research Center, who was acquired by Argon ST in 2006.
Posted by Glen B. Alleman on August 13, 2009 at 03:44 PM in Project Management | Permalink | Comments (6) | TrackBack (0)
|
For those missing the DeMarco post, here's a counter argument from CrossTalk, titled Software Project and Process Measurement.
The notion that measure is of little value is of course unfounded in any software development environment where you are spending someone elses money. If it's you own money, then only you care.
If it's someone elses money, they probably care when you'll be done with the business value they need to implement the capabilities needed for their strategy to actually work.
Posted by Glen B. Alleman on August 02, 2009 at 03:53 PM in Project Management | Permalink | Comments (1) | TrackBack (0)
|
Recent Comments