Leadership

Adaptive Project Framework: A new level of agile development

Robert Wysocki's Adaptive Project Framework focuses on the proposition that, since most current IT projects evolve as they go and begin with uncertain requirements, traditional project methods are not applicable.

In the Agile Project Management classes I teach, one of the first things I do is write two words on the board and then tell my students that these words will be key to understanding everything we're about to talk about in regard to agile concepts.

The first word is adaptive. I emphasize with my students that adapting the project approach to the specific effort at hand is a fundamental concept that underlies all agile methods.

The second word is hybrid. I assure my students that while some agile proponents are almost religious in their insistence that Project Management Institute (PMI)-style, traditional methodologies have no place in an agile environment, my philosophy is that almost every project, every client, and every organization will require us to incorporate some traditional methods into our agile approach. It's my experience that very few organizations desire, or are prepared for, a complete migration from traditional tools, such as project plans and Gantt charts, to a total agile approach founded around the idea that if you're running a traditional product development lifecycle and applying PMI standards, everything you know is wrong.

Adaptive Project Framework

Robert Wysocki, author of one of the foundation texts on project management, Effective Project Management: Traditional, Agile, Extreme, seems to agree; his new book, Adaptive Project Framework, focuses on the proposition that since most current IT projects evolve as they go and begin with uncertain requirements, traditional project methods are not applicable.

Wysocki argues that the vast majority of today's projects include uncertainty in project characteristics that extend far beyond the requirements. He cites typical project elements familiar to traditional project managers, such as:

  • Risk
  • Cost
  • Duration
  • Complexity

as well as project variables such as:

  • Market stability
  • Business value
  • Client involvement
  • Goal and solution clarity

to make the point that since these components vary widely from project to project and from client to client, PMs must be prepared to adapt the project approach taken to ensure a proper fit between effort and approach.

Wysocki uses an analogy to make his point that I think clarifies his ideas nicely. He differentiates between the cook, whose skill lies in following a recipe accurately and consistently, with a chef, who has the experience and skills to create new recipes for each dish and to improvise within existing recipes based on the circumstances at hand.

Traditional PMs who work within strict Project Management Office guidelines are expected to adhere to unchanging development lifecycles; these PMs can deliver consistent results if the goal is well-defined and the solution is understood. Adaptive PMs, according to Wysocki, thrive in environments where the project goals are not yet completely specified and may evolve as the project progresses and where the solution is speculative. In fact, he offers a "magic quadrant" that illustrates his point by pointing to Goals and Solutions as key variables, and Known or Unknown as the defining attributes. When both goal and solution are known, such as a repetitive effort to build a data center by copying exactly an existing facility, traditional methods are probably the best fit. It is in those situations where both the goal and the solution are unknown and where the expectation is that through continuous refinement and incremental delivery, these variables will be refined and discovered, that an adaptive approach is most suitable.

Many of the attributes of Wysocki's Adaptive Framework are familiar to us from our previous reviews of agile methods:

  • they thrive on change;
  • they learn by iterative delivery and discovery; and
  • they are client driven and have an inherent expectation of deep client involvement.

Wysocki addresses this last point of client involvement in-depth. He notes that for the first time the 2007 edition of The Standish Group's famous Chaos Report cites "lack of meaningful client involvement" as the number one reason for project failure. This leads him to assert that the best project management structure, for those high-uncertainty projects that warrant an adaptive project approach, is one in which the client assigns a co-PM for the length of the project, with decision authority for the client side of the engagement. "The co-project manager model is unique to APF," Wysocki notes, "and is a critical success factor for such projects. The most important characteristic is that both parties are equally vested and responsible for the project."

Another unique characteristic of the Adaptive Framework is its approach to requirements definition. Traditional PMs are accustomed to a template-driven approach, such as the Robertson Volere Requirements Specification template, in which the development team questions the client and stakeholders, walking through a voluminous template and often asking questions that, due to uncertainty or limited technical background, the client is unable to answer. Alternatively, many agile approaches offer a story-driven approach to requirements definition. Adaptive Projects take a different tack; Wysocki offers a requirements process based on a Requirements Breakdown Structure, a hierarchical definition that begins with a top-level, strategic project goal and then progressively decomposes that goal into a four-level structure:

  • Requirements
  • Functions
  • Sub-functions
  • Features

He makes a nice distinction between the Requirements Breakdown Structure and the traditional Work Breakdown Structure: "The RBS answers the question 'What are we going to deliver?' The WBS...answers the question 'How are we going to deliver it?'"

Conclusion

When a reviewer calls a book dense, it's often not meant as a compliment, but instead intended to imply that the book is difficult, inaccessible, and obtuse. Wysocki's book is dense, but in the best sense of the word; rather than offering vague concepts and high-minded advice, he presents a clear set of values and fundamental approaches and then presents a detailed execution model that walks practitioners through the process of implementing his ideas. His book is not meant for skimming; every page rewards patient readers with valuable insights and stepwise methods for applying his framework.

Wysocki makes some strong claims for his Adaptive Project Framework. According to him, projects that follow the Adaptive Framework deliver projects faster, cheaper, with higher quality and better business value. He goes so far as to state that his approach delivers successful projects every single time without fail. While I'm not prepared to endorse these claims, it's clear to me that Wysocki's Adaptive Project Framework is a valuable addition to the PM literature and takes the ideas of agile development to another level of reality and pragmatism.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

6 comments
dzache
dzache

I haven't read the book, and I'm not feeling so competent to comment now, but I just want to address this question to Toni - If Wysocki "differentiates between the cook, whose skill lies in following a recipe accurately and consistently, with a chef, who has the experience and skills to create new recipes for each dish and to improvise within existing recipes based on the circumstances at hand."... then - isn't this framework another PM recipe

havenja07
havenja07

This is a wonderful opinion. The things mentioned are unanimous and needs to be appreciated by everyone. I appreciate the concern which is been rose. The things need to be sorted out because it is about the individual but it can be with everyone. =================================== New Technology

robin
robin

Too often and too much, project managers, developers, and others attribute apparently changing requirements to the impossibility of identifying requirements. Such beliefs then continually are confirmed by their proponents? repeatedly not identifying requirements adequately. Instead of explaining difficulties by assuming something is impossible, consider the albeit-less-flattering but perhaps more objective possibility that the difficulties much more may reflect the impossibility proponents? inadequate skills and knowledge. The impossibility excuse virtually assures they?ll never get better at their underlying deficiency. REAL, business requirements change far less than the awareness of them; and they can be discovered much more thoroughly than most people recognize, especially those who?ve already committed themselves to not being able to identify requirements. Most of the apparent requirements changes come from mistakenly thinking the product or system one expects to create is _the_ requirements. Rather, the product/system is a high-level design of a presumed way _how_ to respond to the REAL business requirements deliverable _whats_ that provide value when satisfied by the product _how_. This is not to say that all requirements need to be defined in detail before proceeding or that one should not stay flexible and recognize changes; but one can (and frankly, should) get the high-level REAL business requirements right before embarking on the costly effort to satisfy them. Building and then rebuilding a product may seem like progress and certainly can feel satisfying to the builder; but it?s usually an inefficient way to find out what you really should be building. You can learn more in my related seminars and book, Discovering REAL Business Requirements for Software Project Success.

Jacqinabox
Jacqinabox

Good article. However not all traditional methods refer to WBS. Prince2 is product based and refers to a Product breakdown structure, it focuses on the nouns rather than the verbs. I have been using a fusion of PRINCE2 and Scrum for years. Now I can add being adaptive to my list.

casey
casey

Nice, even-handed job summarizing the APF approach. I find that APF has many of the concepts familiar to product design teams and product lifecycle management methodologies. - Cris Casey Exertus, Inc. 646 770-4585

v r
v r

Success is rationally defined as how well the software meets the bus reqs. If the bus reqs surrounding the goal(s) of the software are not clear, frustration on the part of the developer(s) and bus sponsor(s) is the likely result. Regardless of the method (agile, traditional, etc.) used, the PM must be clear about the deliverable(s) as well as the cost and the time to market.

Editor's Picks