Prototyping and Agile: Twins, Separated at Birth?

PM ChangeAgent Commentary by Stacy Goff.
We’ve written before about the intelligent application of Agile methods in Information Technology (IT) projects: See part 3 of our 4-part 2011 series, The First 10% of a Project: 90% of Success, here in our ChangeAgents articles. This article is a follow up with more insights. And, much has happened since our earlier article.

agile_tightropeAgile is maturing, and moving beyond a focus on the last-half-of-the-IT-life-cycle. For example, we have seen  excellent discussions on “hybrid” approaches. This involves using Agile where it is most appropriate (and where the prerequisites are in place), and using other insightful pm methods where they are more appropriate. That approach in IT, plus increasing use of Agile concepts in areas such as New Product Development, shows promise.

I do still have concerns about a few agile zealots who insist upon contrasting Agile to Waterfall. Competent PMs disposed of Waterfall in the early 1980s. We also disposed of, for the most part, years-long, hold-your-breath-and-wait-forever IT projects. What did we replace them with? Three-to-six-month bursts (we called them iterations) that delivered prioritized useful business functions. Of course, we also identified most of the prerequisites for success:

Read morePrototyping and Agile: Twins, Separated at Birth?

Let’s Start at the Start, and Finish at the Finish!

PM Commentary by Stacy Goff.

One of the greatest challenges in managing projects is engaging the full project life cycle. We too-often see practitioners who believe that the “real project” starts at execution of a preconceived solution. These folks seem to believe that the business case, stakeholder engagement, clear and measurable requirements, solution delivery staging, alternative solutions and approaches, and other essential-to-success actions are a gift from above.

Similarly, many project teams escape to other projects late in the project, before success is even evident. Crucial actions remain, such as defect correction, warranty period adjustments, follow-on change orders (chargeable, of course), that increase the return on investment of successful projects, and proof that you met the business need, and supported your sponsor’s strategy.

middleGiven this syndrome, these sadly misinformed project managers and teams should more accurately chart their projects’ precedence diagrams more like the one at left; after all, they are starting and ending their part of the project in the middle!

startMeanwhile the more-savvy project teams (or luckier teams, as the case may be) follow the more effective, more success-oriented approach, which starts at the start, and finishes at the finish. This is shown at the right.

Why do less-effective teams skip the most important parts?

Read moreLet’s Start at the Start, and Finish at the Finish!

Recycling Our Six W’s For Managers In The Middle

PM Commentary by Stacy Goff.

We’ve used the Journalist’s Six W’s for over 25 years now in project kick-off, to help business case analysis and bring all the stakeholders onto the same page. And recently, working with a stellar group of Managers in the Middle, those people who manage project managers and their teams, we came up with a new (for us) use of the Six W’s.

Background on the Six W’s
Originally established as part of our IT Methodology, THE Guide, and Co-Pilot: Small Project Guide in the mid-80’s we use the Six W’s to perform opportunity analysis. We’ve used the right selection of the W’s, in the right sequence, with many, many classes of project managers, customers, managers and team leads. The W’s we use, in the only correct sequence for project delegation, are: What, Why, Who, Where, When, and How. We admit to playing loose with the w’s, when people point out that How is an H, not a W. We assert that it has its W at the end because How is the last W to understand.

Some of the learning dialogue that accompanies the W’s is that there may be multiple Whens:

  • When does the organization need the result (the must)
  • When can the team deliver it? (the can)

We assert that the competent team can always show how they could beat the must (deliver faster) by 25%. In fact, if they cannot perform this simple analysis, we doubt if they understand enough about the project to manage it successfully: They are not yet competent. This is the type of learning, that causes Executives who see it to ask: “This is powerful stuff! Do our people know how to do this?” The answer is usually something like, yes, they do this in each project they begin, but you have six layers of managers between your teams and you, and part of their job is to filter out the information they think you don’t need. But we may be getting ahead of ourselves. We’ll come back to that thread below.

Read moreRecycling Our Six W’s For Managers In The Middle