Opening, Adapting and Closing Often

I continue here to expand my set of “rules” of Lean PM, following Hal Macomber’s comments on my original four rules series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Another lean principle Hal said I had left out was the necessity to PDCA everything (the Deming Wheel – http://en.wikipedia.org/wiki/Shewhart_cycle). Hal notices in his blog that “much has been made of the tools, techniques and methods of lean ways of working. But behind it all is Deming’s (Shewhart’s) Plan – Do – Check – Adjust cycle. It’s the embodiment of the scientific method. No company does it better than Toyota. Make it your habit.” Hal has however revisited the PDCA acronym by replacing the original meaning of the “A” (Act) by Adjust. And I will also revisit, because I believe the PDCA cycle, as stated, does not clearly illustrate what should be project work.

In the current edition of the PMBoK (3rd ed., 2004), PMI also acknowledges the importance of the PDCA cycle in project management, but goes on promoting its own version of it, the IPECC cycle (Initiate, Plan, Execute, Control and Close). There are slight but significant differences between those two cycles, differences that mirror those between recurrent operations and projects:

• PMI “I” (Initiate) is inherent to projects (they start somewhere), hence not included in the more generic PDCA cycle
• PMI “P” (Plan) is similar to Deming “P” (Plan)
• PMI “E” (execute) is similar to Deming “D” (do)
• PMI first “C” (Control) is equivalent to some extent to Deming “CA” (Check, Act). Continuous improvement in project management requires a special kind of acting to handle major project uncertainties and inherent changes. So for projects, Adapt would be a better word than Act and, I believe, more representative of high-uncertainty projects reality than the word Adjust
• PMI second “C” (Close) is also inherent to projects (they have to close, while we do not want to close operational business processes), hence also not included in the more generic PDCA cycle. Granted, one could argue that Acting in the case of a project includes Closing it.

Hal said that we had to “PDCA everything.” The word everything is, for me, the key to the Lean PM philosophy and is related to LPM rule No. 2 (Track small concrete promises that you can see evolving over time). Everything, for me, means: each activity, each deliverable (daily and weekly promises/deliverables if you think Lean or Agile PM), each work package, each phase/stage of the project as they evolve.

So I submit that, for projects, we have to IPDCAdC continuously. Initiate, Plan, Do, Check, Adapt and Close everything. Open-Adapt-Close often. Open new work, adapt to change as you do it, and close it to the satisfaction of all stakeholders. And one must not forget that some projects need to be terminated before they are completed, if they cannot deliver what is required; so Close can also mean Stop!

In acknowledgement of Hal’s revisited comment, here’s Rule number 6 of 8 of Lean Project Management: The Open-Adapt-Close Often rule.

Rule No. 6 of LPM. Open-Adapt-Close, Open-Adapt-Close, Open-Adapt-Close… all the time.
The IPECC cycle is a recurring process; this recurrence is the true key to successful projects, lean-influenced or not. In order to close a project, you have to open-adapt-close formally at the phase level, to open-adapt-close formally at the work package level, to open-adapt-close for each required deliverable (small concrete promises), to open-adapt-close each required activity undertaken.

I am writing this on the New Year’s Eve, getting ready to say farewell to 2008 and welcome 2009. This is the time when we raise our glasses and wish each other the best of things and revisit our own aspirations for the months ahead. It’s the time of reflection and hope, decisions and, often, concessions.

For whatever aspiration you have for 2009, I wish you that you have enough resources, determination and support to carry it through. I wish you good health, much happiness and every success you deserve.

Since the economic news from around the world is far from fantastic, I hope all organizations worldwide world will remember why they exist, will stick to their core values and always act responsibly towards clients, shareholders and employees. Since this is a project management blog, I also wish them good project management. It is critical today more than ever, because a tough economy has an unmistakable trait of being able to separate success from failure and amplify the consequences of both by a factor of thousands.

I must explain what I mean by good project management. I hold the discipline of project management to be a core competency of every senior professional, whether manager or executive. I have been and will remain critical of the current state of the project management designation which is so incredibly easy to obtain that the professional value of a good project manager has become diluted by meek, under-qualified individuals who could barely manage my cat’s breakfast, let alone a project. I have met with whole organizations besieged by hordes of such people, for they were very cheap to acquire. They have turned into expensive glorified clerks, making sure that timesheets are submitted on time and status reports furnished before the set hour, notwithstanding the poor content within them.

There is little place for such project management anywhere when the times are tough, and these people will probably among the first to go. It is high time for good project management, where project managers are:

• Knowledgeable. Understanding the problem domain and having the general business knowledge is critical. I have now lost count of my conversations with individuals who could not tell me the business impact of their project, could not read a basic P&L statement and had no people management skills.
• Resolute. Have you seen projects that are paralyzed because every minute operational decision is brought in front of the steering committee? It’s a sorry sight! I recently spoke to a senior PM with years of experiences, who confided to me that his project sponsor had made, as he believed, a suboptimal project decision. I asked him if he shared his concerns with the sponsor. No, as it turned out, on the account of the sponsor being “a very senior guy.” Within her scope of control, a project manager must be the ultimate decision maker, and granted, some of the calls will be tough. For all other project decisions, the ability to simply express one’s opinion as a person closest to the project is incredibly important.
• Committed to learning. My observations suggest that there is a wide gap between the knowledge that project managers require, and that they are getting. Too often, an individual submits deludes herself or himself that she or he knows everything there is to know about the subject, while in fact knowing very little. By way of an example, one of the critical skills for a project manager is decision making, the ability to assemble a business case, weighing in financial, strategic and other variables. Really successful project managers recognize that there can never be the “end of learning” in this subject. I see them in my courses on Business Cases and Cost-Benefit Analysis, the nearest taking place on February 2, 2009. They ask provocative questions, yes, and I am happy to know that there are project managers like them out there.

In every profession, there are those who are good at it and those who are not. Difficult times are very effective in separating diamonds from the sand, and I have no doubt they will. In the difficult time we’re going through now. The good news is that the future of every project manager is largely in his or her own hands.

Here’s to good project management. Happy New Year!

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya can be reached at [email protected] or (905) 278 4753.

It seems that there are a few things that we just can’t avoid. Measures of what we do are one of them. And with the year coming to a close, there is often reflection on ‘how we’re doing’.

Project management and related processes are no exception to this. I’ve been recently involved in an effort to develop a release management process that dovetails into a project management framework and application development life cycle process. As you might expect, a few questions come up on metrics:

• What should we measure in the process?
• How should we go about it?
• What should we focus on first?

When looking at measures of any new process, my preference is to keep the number of items measured to a minimum. It’s important they are easy to capture and, indeed, reflect what you are actually trying to monitor.

In determining what should be measured, it’s useful to consider four groups of measures: scope and scale, effectiveness, efficiency and sustainability. For each group I start with a basic question. If we were looking at an organization’s project management processes, these are the questions one might consider important:

• Scope and scale: How many projects and what types of projects are we supporting?
• Effectiveness: How effectively were projects in meeting their objectives?
• Efficiency: How well were the activities conducted during the projects?
• Sustainability: What has been done to ensure the project management processes remain a ‘value add’ to the organization?

From here you can build a series of metrics each question and grouping. So for effectiveness, we might measure the number of projects we completed on time; simple and easy to measure. Such simple measures provide powerful views when consistently collected over a period of time.

Like death and taxes we can only avoid being measured for so long. Unlike these other certainties why not embrace a metrics program if for nothing other than to record and celebrate how well we’re actually doing?

Have you ever been asked to review a contract at the start of a project only to find out some of the details are missing? Have you ever come into the middle of a project only find out that the service levels in the contract are not being met? How about contracts where service levels are not even being tracked? It makes you ask the question
There are too many instances where organizations spend tons of money on legal fees and resource time in the negotiation of a contract, only to never look at it again. The whole purpose of negotiating service levels in a contract is to be able to hold the supplier accountable for a minimum level of performance. If no one is going to track against those service levels, then how does one know that they are being met? If an organization negotiates prices for products or services, what is a reasonable time-frame before those rates need to be reviewed for validity?