Agile PM Process Grid-2.12 Contract Control


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post concerns the process of controlling agile contracts that were entered in process 2.3.

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed the three different types of contracts in traditional project management to give a contrast to the agile contracts discussed in this post.

Traditional PM Contract Types

As a recap, here are the three types of contracts used in traditional PM.

Three Types of Contracts in Traditional PM

The three types of contracts in traditional project management are:

  1. Fixed price
  2. Time & material
  3. Cost reimbursable

In terms of cost risk, you can list the three types of contracts in the following way, where a higher cost risk to the seller is to the left, and a higher cost risk to the buyer is to the right.

Fixed Price –> Time & Material –> Cost Reimbursable

Fixed price contracts tend to be used when the scope is predictable, and thus a fixed price is readily obtained for the component.   Cost reimbursable contracts, on the other hand, are used for when the scope is NOT so predictable, and thus the cost of the component cannot be so readily obtained.

Inherent in the fixed price and cost reimbursable contracts are the tension between the seller and buyer in terms of cost risk; fixed price favors the seller and cost reimbursable favors the buyer.   That is why there are mechanisms in place (ceiling price, incentive fee, etc.) to make the cost risk more equitable on either side.

Agile Contracts Types

In agile contracts, on the other hand, all three types try to balance the cost risk between seller and buyer, and the difference comes to not how they are structured in terms of cost, but how they are structured in terms of time.   Agile iteration contracts are done for the duration of an iteration.  Time & Material contracts are done for an arbitrary period of time.  Phased development contracts are done on a quarterly basis.

One feature that agile contracts have in common with traditional PM contracts is that they tend to be risk management tools.   In the case of traditional PM, the focus is primarily on cost risk.

  1. Agile Iteration Contract–this is based on each team delivering agreed upon features to defined quality standards by iteration end.   NOTE:   The Product Owner is NOT allowed to change the iteration backlog DURING the iteration.
  2. Time & Material–this is based on a customer continuing to pay a customer during an agreed-upon time period until such point that the customer doesn’t see value being added, at which time the customer stops paying and the contract ends.
  3. Phased Development–this is based on the team achieving a successful release of the product.

In agile contracts, cost risk is a factor as well, and the time period of the contract is chosen based on the needs of the customer and the size of the project, but the agile contract helps manage other areas as well.   Here is a chart showing how the four areas of scope, risk, communication, and cost management (related to issues of invoicing and payments) are dealt with in the three types of contracts listed above.

CONTRACT TYPES Agile Iteration Time & Materials Phased Development
Scope Management Mutual, based on team delivering agreed upon features to defined quality standards. Dependent on customer seeing continued value. Funded quarterly following each successful release.
Risk Management Mutual, using product backlog grooming and iteration backlog commitments. Customer carries change management risk; budget may be used up w/o achieving expected value. Mutual, limited to one quarter’s development costs.
Communication Mgmt. Project scope confirmed at the start of each iteration. Interdependent need to actively prevent dissatisfaction. Interdependent need to secure additional funding.
Cost Mgmt. Can be a T&M or Earned Value agreement, usually with cost ceilings. Invoice sent after agreed-upon work period, may include cost ceilings. Invoicing is paid within funding limit, with iteration contract addendums.

The overall point to remember with agile contract is that the relationship between the customer and team is paramount; the contract is merely a formalizing of that relationship and a way of dealing with risks that may occur in the future so that the customer and team can essentially put them aside and focus on their working relationship in the present.

Controlling Agile Contracts

The first word that should come to mind when thinking of the word “controlling” in project management is the companion word “monitoring”.   First you monitor to see if the contract is being carried out as planned, and then if it isn’t, THEN you control the situation, either bringing it in line with the contract or modifying the contract as necessary.

The key point is that, just with traditional project management, a contract divides the shared risk between the parties and thus defines what the pressure points of trust are between them.

The best practice in monitoring a contract is to define a small number of high level user stories that include acceptance criteria that are the conditions of satisfaction for each story.   The conditions of satisfaction need to be discussed during the process 2.3 so that the development risk can be seen as adequately being covered and equitably being shared in the course of the agreement.

Any effort spent defining the conditions of satisfaction will pay for itself in the time and cost avoided having to mitigate any undefined requirements later.

Another element of good contract control is good estimating, so that both parties can realistically determined the amount of risk each party is sharing.

Periodically monitoring the contract is not questioning the trust of the parties; it is building a solid foundation so that such trust can be built upon during the course of the project.

The next post covers the issue of earned value management in agile projects.

Agile PM Process Grid-2.12 Accounting Control


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post covers Accounting Control, one of two parts of process 2.12 (the other one is Contract Control).

Accounting control is measuring performance against a cost baseline, which is created in the following steps:

  1. Create a release plan
  2. Forecast cost per iteration
  3. Establish a cost baseline

However, at the end of each iteration, just like the grooming of the product backlog, the cost baseline should also be reviewed before each iteration and re-calculated based on any changes made to the product backlog (which may effect step 2 above) or the release plan (which may effect step 1 above).

If an earlier cost estimate has been decided to be mistaken, then the team needs to alert the Product Owner or customer/proxy to discuss the implications so that proper decisions can be made.   Any changes must be negotiated with and approved by the customer/proxy.

For most organizations, doing accounting control at the release level is not enough; it must be done at the story level in order to get control of the cost baseline.

The other type of control that must be maintained is that of Contract Control, which is the subject of the next post.

 

 

Agile PM Process Grid-2.11 Product Feedback


John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now covering the set of processes done in the control process group of an agile project, specifically those processes that have to do with the knowledge area of Value-Driven Delivery (equivalent to the “Quality” knowledge area in traditional waterfall project management).

In the last process 1.11 Product Demonstration, a validation process is done prior to a Release of the project.   Thus it has the same goal as a Review meeting, but is obviously at a higher level of importance because it is done prior to the Release of the product to the public.

Well, if you show the stakeholders the product, there are two possible reactions:

  • hey, that’s just what we asked for!
  • wait a minute, that’s not exactly what we asked for

And I suppose a third possibility is, “hey, that’s just what we asked for before, but since then we’ve changed our minds.”   In any case, if there are certain features of the product which do NOT meet the satisfaction of the stakeholders, then the process 2.11 Product Feedback gives the stakeholders the chance to stake specifically what needs to be changed in order to meet their expectations.

This will send the team back to revise the product according to the new shared understanding of the requirements as set forth by the customer and interpreted by the team.

The next post will go to the next knowledge area, that of Adaptive Planning, to see what takes place in an agile project during the control process group that is related to that area.

 

 

 

 

Agile PM Process Grid-1.9 Product Demonstrations


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now writing about those processes that occur during the Control process group.    The first process is one that deals with the first knowledge area, that of Engaging External Stakeholders.

In process 6.7 Review Meetings are done at the end of each iteration.   Product demonstrations are, like review meetings, product-centric presentations of completed work products.   However, they are done not at the end of each iteration, but prior to a Release.    The purpose is get feedback from the stakeholders that validates the value that the team has created for the end user.

Like the review meetings, features are demonstrated that were actually completed, and any features that were not completed are documented, along with the reason why they were not completed.

The purpose of the meeting is to align the team and the stakeholders so that a sense of trust is fostered which allows the team to remain focused on the goal of the Release.

The next process is actually part of the same Product Demosntration, but done for a different purpose, for value-driven delivery.  That is process 2.11 Product Feedback.

 

Agile PM Process Grid–The “Control” Process Group


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The previous posts have covered the “Initiate”, “Plan”, and “Iterate” process group of an agile project.   Tomorrow I start on the “Control” process group, but I first want to define what I mean by that term of “process group”.   Why do I use this instead of the word “phase”?    Phase implies a sequence that goes more or less from one set of processes to another.   In reality, after the initiate and plan process groups, an agile project actually shuttles back and forth between the “iterate” and “control” process groups.   In an iterate process group, you’re working the plan.   At some point you want to take a step back, monitor the work you’ve been doing, and see if you are conforming to the plan.   If not, you have two choices

  1. Re-adjust the work to the plan, i.e., get back on track
  2. Realize that it is the plan, not the work, that needs to be changed.   Here you are changing the track itself.

In any case, this series of “course adjustments” goes on continuously in an agile project.

The first process in this control process group is one which covers the knowledge area of “External Stakeholder Engagement”; it is the process 1.9 Product Demonstration, and is the subject of the next post.

 

Agile PM Process Grid–7.5 Metric Tracking


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

In process 7.4, I discussed the process of Metric Definition, which is set up during the Planning phase of the project.   In the Iterate phase, it is necessary to track the metrics that were set up in process 7.4.   This is the process 7.5 Metric Tracking.

The team must help set up the metrics, and then once they are set up, to have the discipline to track performance against those metrics.   Many of these metrics will be the data points to be discussed during the Review and Retrospective meetings, and the better the data, the better the discussion at those meetings.

This discipline forms the daily practice of continuous improvement on a project, which should always be a goal in an agile project.

The next post starts the Controlling phase of a project.

 

Agile PM Process Grid-6.8 Osmotic Communication


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference” creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Communication knowledge area that are done during the Iteration phase of an agile project.    This process is 6.9 Osmotic Communication.

What is osmotic communication?    Generally there are three main forms of communication:

  • Interactive or face-to-face (one-on-one)–when information is exchanged between people
  • Push (one-to-many)–when information is sent from a centralized location to those who need that information
  • Pull (many-to-one)–when information is put in a centralized location, and those who need that information pull the information from that location when it is needed

Osmotic communication is a form of pull communication when members pick up information from a centralized location, but rather than having the source be a static set of files, the information they are overhearing is in itself interactive communication, i.e., conversations occurring in a common area.

The top form of interactive or face-to-face information is recognized as THE most effective channel available.   If these effective communications are occurring in a common area, then a second level  of benefit can be gained by having people overhear those interactive communications and thus being made aware of current insights on the project.

Of course, osmotic communication presupposes colocation in order for it to work.   What are some of the constraints on the effectiveness of osmotic communications?

Have you ever been to a networking function with more than 50 people?    In order to hear your own conversation without being drowned out by those of others, you need to breakaway into a quieter corner if you are to have a meaningful conversation amidst the din of the background noise of everybody else trying to have a conversation.   This points to the fact that osmotic communication works best with small teams.

However, if teams are larger, than just like in the example of the networking session, it is good to have breakout spaces or even a private office available for conversations that need to be held in private without the possibility of being overheard.

If teams are distributed rather than collocated, then you must work on fostering trust between team members and creating digital spaces where conversations can take place in order to achieve the best communications possible on a team, no matter where the team members may be.

The next post gets into the knowledge area of continuous improvement, and how this is implemented during an iteration.