Project management revisited

I've written about project management before multiple times. A new tool has become available, and so I thought it time to provide an update.

Project management was part of my professional life as an engineer from the start. My first manager took a course in Netzplantechnik and had me manage my design project using a paper PERT chart. At my second company, mainframe computers produced PERT data in tabular format, which I found far less user-friendly but certainly more voluminous. At my third company, I discovered and used MacProject, one of the friendlier and more intuitive project management programs I have seen.

Yet my third company also introduced me to process management and continuous process improvement. I started in manufacturing engineering and heard many a statement about improvement being continuous, having no end. I saw and participated in the great strides such approaches could make, even as we did run specific projects to accomplish specific objectives.

When I returned to a product development organization as R&D productivity manager, I struggled with what I saw as a project vs. process dilemma: projects seemed to be closed systems on far too many levels to be the unifying organizational approach. While certainly highly useful, they didn't seem to capture the reality of the world nor enable the strides I had seen a process focus capture. My manager was patient, reminding me of the business advantages of a project orientation that focused on achieving a specific goal with specified resources over a specific time frame.

With a few more years to reflect on the process vs. project issue, I now see the ideal as both-and, not either-or. To manage a business, there are many times when we are best served by dedicating fixed amounts of resources and schedule to achieving defined goals, and those call for projects and project management. Yet, to be competitive and to make a sustainable contribution requires a steady focus on getting better, a focus that isn't limited by a project release (or completion) date. I discovered an early statement of the idea of blending a project and a process focus in Experiences with Defect Prevention in the IBM Systems Journal from 1990, and I applied their notion of an action team to a project that reduced the prototyping time of printed circuit assemblies by 83% ("Emphasis on Business, Technology, and People Cuts Turnaround Time at Hewlett-Packard's Lake Stevens Division," National Productivity Review, Winter 1998-99).

I've updated the Project Management section of my Links page for new software that has become available. While GanttProject and TeXProject are still useful (TeXProject more for those who use LaTeX regularly), there's a newcomer to the scene: OpenProj™ by Projity. Some see that as a possible adjunct to OpenOffice.org; others see it as a tool that works with Microsoft Project files.

There are other solutions, especially for online collaboration. eProject offers a well-known commercial solution, and Projity offers its Project-ON-Demand™ SaaS. PHProjekt is a free alternative.

Whatever tools you pick, it's most important to think. As I related in the first links above, paper and pen with good project management approaches can work quite well; complex tools with poor approaches may get you nowhere (of course, complex tools may be necessary to manage the complexity of large projects). Certainly get the basics of project management down, but keep an eye out for new ideas such as critical chain theory (a decade old now) which may help you do better, and integrate project and process approaches in ways that serve your organization well.

Incidentally, chapter 11 of the novel Critical Chain by Eliyahu Goldratt is available online.

Rehearsing

I often help people with presentations, and I've noticed that those who rehearse seem to be those who do better. Now Garr Reynolds of Presentation Zen has done an excellent job of explaining the creative process of presenting ideas to others in his Steve Jobs and the art of the swordsman.

Note the two keys to presentation success:

• Intense rehearsal in a team setting
  
• Absolutely no attention to technique or form in the actual presentation
  

Reread Garr's comments, if you need to, and note comments such as, "...once we allow our mind to drift to thoughts of success and failure or of outcomes and technique while performing our art we have at that moment begun our sure decent." [sic]

How can we possibly get through a presentation while following the second key? By following the first key until we have internalized what we want to say, how we want to say it, how others will hear it and respond, and what we can do if something goes differently than we expect. Then we have to rehearse it some more.

As someone once noted, we often rehearse something until we get it right. That means we may have done it wrong 20 times and right once; which do you think will stick with us better?

I think the same thing applies in other areas of our professional lives, and I think Dietrich Dörner and Harald Schaub might agree. That's why I wrote A somewhat unified view of decision making: to suggest the importance of spending time wrestling with what we do at a time that's apart from the actual doing. Whether we use computer simulation, scenario planning, role playing, or something else, the opportunity to rehearse what we do professionally before we do it and to learn from what we actually do afterwards to improve for next time is exceedingly valuable. And it's the cyclic action learning that helps us improve and helps keep us from getting fixated on a bad idea.

If you're still thinking of presentations, check out Garr's presentation tips.

Tom Peters' suggestion on ISO 9000 and Six Sigma

Have you ever known Tom Peters to suggest anything? Well, he didn't start now: see his "Told You So!" rant on ISO 9000, Six Sigma, and the like.

I've said in the past that I don't always agree with what Tom says, but he does almost always make me think. To what thoughts does this lead you?

Peer assists

Action learning has long had a process known as learning sets to help people develop the understanding they need to address their own problems. Now Bellanet and the University of Ottawa have described something quite close to this in a short Flash session on Peer Assists (also available in French). (Thanks to colleague Nancy White of Full Circle Associates for the lead.)

I've found that journaling can be a helpful adjunct to such a process. Perhaps the learning logs Bob Williams and I created may be of help to you. As a bit of practical advice, I've also found that it helps to inject new ideas into your thinking, either by reading or listening, while reflecting through journaling and working with a learning set.

If you're interested in studying action learning or its close cousin, action research, check out the excellent, free, online (asynchronous) AREOL course offered twice a year by Bob Dick. AREOL 25 begins February 2007; sign up soon!

Listening: how I started doing project retrospectives

When I became software quality manager at my former company, responsible to help improve the software development process so our products would make our customers even happier, I realized that reading up on processes used elsewhere and then telling the software engineers how to do their work would be a quick route to becoming excluded and ignored, but what else was there?

I was a member of the then-active arlist-l mailing list, and I took the action research notion of a learning set to heart. I went to a project team and offered to facilitate project retrospectives. I'd listen, I'd take notes, I might ask a few clarifying questions, and then I'd summarize and publish the notes.

It seemed very important simply to listen, and it seemed very important to produce summaries that were useful, approachable, and complete, so each report started with a 1-2 page summary and action plan (theirs, not mine), followed by a more complete transcript of what seemed like key quotations from the tape I made as data. That is one of the few circumstances in which I have taped sessions, for I wanted to make sure I reported their words and not my interpretation.

The first retrospective or two were published both in paper form to all project members, project managers, their managers, and the R&D manager and in electronic form on the internal 'notes' (USENET) system.

After a couple of retrospectives with various teams, one project team said they were tired of repeating the same problems in each project. Could I help them figure out how to change? We agreed that I'd take weekly data, this time from a short survey, and feed that back in the same manner.

Without giving you the entire history, I listened, asked clarifying questions, and summarized. They spoke, read, and changed. That work, coupled with a few other initiatives, began to make a real, noticeable difference in the development of products, their quality at release, and the timeliness of the releases. Product release decisions, which had been big, important events, became more of a check-off, for there were no longer surprises, at least with project teams which had made heavy use of retrospectives.

As evidence of the magnitude of the change, a project team member came to me one day, incensed that a project manager leading another project accused her team of lying on their retrospectives (I don't think that project manager's teams took me up on the retrospectives offer). He said that no project could run as smoothly as their retrospectives had shown. While I would have wished that his projects had tried them, too, and I would have wished that he hadn't accused the other team of lying, it did make clear the distance we had come with a very simple approach. That was the start of my work doing retrospectives.

How is your organization learning from past experience to improve in the future?