       |
|||||||||||||||
Adaptive Project Framework Part 2: Version Scope |
|||||||||||||||
|
Home > Articles > Adaptive Project Framework Part 2: Version Scope by Robert K. Wysocki, Ph.D. July 18, 2003 APF is an approach to a class of projects for which neither the traditional nor the extreme methods are appropriate. APF is entirely compatible with the PMI PMBOK Standards. This series is derived from selected content from the 3rd edition of my book Effective Project Management: Traditional, Adaptive, Extreme.  
An Overview of the Version Scope Phase It concerns me how informally we often engage in the initial task of defining a project with our client, customer or user (I'll use "client" to represent all three.). Later in the project, when things start to go wrong, we wonder what happened. It's no secret that project failure rates are unacceptably high. What doesn't make any sense is that we don't seem to learn from our mistakes. We just keep on doing the same thing project after project. Let's agree right now that we will take the scoping exercise very seriously.
As shown in Figure 1, Version Scope is the initiating phase in an APF project. The most significant characteristic of this phase is that from the very start it meaningfully involves the client in all of the tasks that make up the initiating activities. We often experience difficulty in engaging the client. It's not a perfect project world out there. If you remember one thing from this article, remember this: don't start the Version Scope Phase unless and until you get a commitment from your client to be fully involved.
As project manager, it is your responsibility to get that commitment. I can't stress enough just how important this is. In fact, it is so important to me that I have postponed starting the Version Scope Phase until I have that partnering commitment. I won't argue the fact that that means playing hardball with your client. But why proceed when you know that you are just asking for trouble?
Figure 1: The Adaptive Project Framework
Version Scope Deliverables The best way to introduce you to the Version Scope Phase is from the perspective of its five deliverables:
Let's briefly discuss each one.
Conditions of Satisfaction I am told that the Conditions of Satisfaction (COS) has its origins in IBM Canada. I've never been able to verify it. All I know is that it works and it should be in the toolkit of every project manager. The COS is a structured conversation between you (or your core project team) and the client (or a representative group). It may be a brief one-on-one conversation between two people (project manager and client). It might be a formal one week planned meeting with several participants. It might take any one of several forms between these two extremes.
Whatever form it takes, it is a face-to-face conversation. Let's take a high-level look at that structured conversation. The client makes a request and a discussion follows between you and the client until the client knows that you understand the request. You then respond to the request with a statement of what can be done. Your response is discussed with the client until you know that the client clearly understands what you will be able to provide. Any discrepancies between the client's request and your response can then be negotiated to closure.
There are two important benefits from the COS. First, you and the client have established a vocabulary--a common language that you will use for clear communications all through the project. While this may sound trivial, it definitely is anything but trivial. With reference to your own projects, can you say that you and your client really understand one another? Maybe, but probably not. Second, you have a negotiated agreement. The negotiated agreement becomes the foundation on which the project proceeds. You will use it for problem solving, conflict resolution, and decision making.
Project Overview Statement The deliverable from the
The POS has five parts:
The POS is approved over the signature of the project manager and the decision maker from the client side. For a complete discussion of each of these five parts, refer to Effective Project Management, 3rd Edition.
Cycle Parameters Within the
A few comments on cycle length will help put APF in perspective. APF cycles are typically 2 to 6 weeks in duration. Extreme Project Management has the same general specification. The early cycles should be shorter than later cycles. The reason is simple: You can more fully engage the client by getting deliverables to them early and often. That will keep them involved and enthusiastic about the visible progress they see. Later cycles can be lengthened without the risk of losing client involvement. They will have been hooked by that time.
Mid-level WBS If you don't know the future, why plan for it? Remember that an APF project is one where the goal is clearly defined but how to reach it is not. That means we don't have a clear definition of the activities and tasks to be worked on. That means we can't build a complete WBS. To even try means we would be making guesses--some wild, some not. What a waste of time. So we are not going to do that. What we will do is build a partial mid-level WBS with what we do know. We'll depend on the learning and discovery dynamics that take place in later cycles to fill in the missing parts of the WBS.
Prioritized functionality What we have to operate with is a list of functionality as identified in the partial mid-level WBS. Don't let the qualifier "partial" bother you. Remember that future cycles will include learning and discovery experiences that will help us complete the WBS. The missing part is a piece of the future. We can't describe it now and so we are not going to waste time thinking about it. Period. All we have to do right now is prioritize the functionality that we know will be in the final solution. There are many ways to effect that prioritization and I won't go into those here.
In Summary We've seen a 60,000 foot view of the Version Scope Phase from the perspective of the five deliverables that are produced. So far you might recognize parts of it as similar to the initiating activities of the extreme project management approach and that would be a correct observation. There is one marked difference however. In an APF project the client is the central figure and that is why I have stressed the importance of having the client meaningfully involved. In collaboration with the project manager, the client determines the direction of an APF project. Think of the client as the pilot and the project manager as the navigator and you'll have a good understanding of that relationship. That condition will become very obvious as we proceed through the remaining phases.
APF is a work in process. It was built as part of recent client engagements and is not fully baked as of this writing. You may read more about it in the 3rd edition of my recently released book Effective Project Management: Traditional, Adaptive, Extreme. I would certainly welcome any comments on this article or the book. You may reach me directly at rkw@eiicorp.com.
The 3rd edition of Effective Project Management: Traditional, Adaptive, Extreme by Robert K. Wysocki, Ph.D. of Enterprise Information Insights, Inc. is due out at the end of July, 2003 (John Wiley & Sons Publishers).
Related Content
sponsored announcements and special offers
You can do this!
Earn your master's degree in project management without putting your life on hold at GoUWP.com! Apply today at GoUWP.com for 100% online courses, 45 PDUs each. No entrance exam. University of Wisconsin- Platteville’s MS in Project Management is globally accredited by PMI. Combine academics and real-world scenarios for a 360-degree education. If you have a distributed team, what are you trying to achieve with Agile approaches? Isn't Agile more for co-located teams? There are eight key benefits to working in a distributed Agile environment. A new report from ProjectsAtWork looks at each of those benefits – and how you can achieve them.
Most business and IT executives agree that any company able to rapidly deliver software of high and predictable quality with minimum budgets enjoys a significant advantage. However, practical experience shows that the challenges associated with software quality remain largely unsolved. Download the white paper Uplift Quality with Requirements Driven Testing to learn fundamental principles of Requirements Driven Testing.
|
 sponsors
vendor offers
vendor events
| |||||||||||||
|
| |||||||||||||||
