Tag Archives: Business Case

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 now maturing, and moving beyond the last-half-of-the-IT-life-cycle. For example, we have seen excellent discussions on the “hybrid” approach. 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 of the agile zealots who insist upon contrasting Agile to Waterfall. Competent PMs moved away from “pure” Waterfall in the early 1980s. We also disposed, for the most part, of years-long, hold-your-breath-and-wait-forever IT projects. And, we eliminated the reams of never-used unneeded documentation–retaining only the useful stuff. What did we replace these 1960s-era artifacts with? Three-to-six-month, intensive bursts (we called them iterations, or increments) that delivered prioritized useful business functions.

Prerequisites for Success

Of course, in addition to speeding useful delivery, we also identified and implemented other key prerequisites for project and business success:

  • A good, high-level project plan;
  • A clear business case;
  • Understanding of the information needs and data structures;
  • Customer-driven high-level business requirements;
  • Risk assessment, and mitigation responsibilities;
  • The right talent assigned, the right amount of time; both on the IT side, and from customers;
  • Facilitated sessions (Rapid Initial Planning and Joint Application Design) for fast project planning, and requirements elicitation in 1-2 weeks;
  • And, all the other factors mentioned in part 3 of our Success series, mentioned above.

Continue reading

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

PM Commentary by Stacy Goff, ProjectExperts CEO.
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!

start
Meanwhile 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? Continue reading

Recycling Our Six W’s For Managers In The Middle

PM Commentary by Stacy Goff, ProjectExperts CEO.
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. Continue reading