Navigating Your Changing Role Between Traditional and Agile PM

At the PM Symposium 2015 event held at the PMI Chicagoland chapter last Friday, I had a chance to see several presentations.   One in particular caught my eye:  it was called “Traditional PM, Meet Agile:  Navigating Your Changing Role” and was presented by a team of two people.   Jeff Singleton who runs The Project Factory, Inc., and Jeanine Izzo, who runs Viage Partners, Inc.   Jeanine was the voice of traditional PM, and Jeff represented the voice of agile PM, because he has had more work experience in the agile world than Jeanine has.

The Project Management Continuum

In the entrance to the presentation, they had a poster which had the words THE PROJECT MANAGEMENT CONTINUUM on it, with T for Traditional at one end, and A for Agile on the other.   They had people mark with a circle where they stood on their PM journey in transitioning from traditional to agile project management, and they also had people mark with a square where their company stood in that transition.

The results of the informal survey were as follows:

If traditional is -3, and agile is +3, with 0 being the midpoint, the median response was somewhere between -2 and -1.   NO one was as far as +3 on the agile scale.   Interesting, it seemed as if the companies were clustered more between -3 and -2, which shows that people are farther along the way to transitioning to agile than their companies.   This became a theme in the Q&A session after, where many people said as project managers, their teams were agile but that management was traditional, and one of the challenges they faced was, not only running an agile team, but also translating the progress on the project into “traditional PM” language so that the management could understood what was going on.

The main point I liked about this “continuum” survey was that it is NOT about “traditional vs. agile”, it’s about learning how to speak two different PM languages if you will so that you can translate between the two worlds with agility (pun intended).

5 Comparison Areas

The next section of the presentation was a compare and contrast exercise, with the “contrast” part coming first.   Here are five areas of comparison between traditional and agile PM and a sample of each comparison that was given at the presentation.  I don’t want give the entire content of the presentation, because my hope is that those who are interested can contact Jeanine Izzo at (630) 833-8357

and Jeff Singleton at (847) 710-7137

to arrange to have this presentation done at your company or organization.

Topic Traditional Agile
1.        People/Teams Accountability by PM Accountability by Team
2.       Structure Robust Documentation Value-Driven Documentation
3.       Mindset Change Viewed as a Disrupter Change Viewed as an Opportunity
4.       Tools Driven by Policy Driven by Need
5.       Communication Manage Communications Facilitate Communications

You can see that the focus is different for each topic between traditional and agile PM.

5 Skill Areas

The main point in this section of the presentation was to emphasize that knowing traditional PM is not a barrier to learning agile PM; there are certain skill sets that carry over from traditional to PM, such as

  1. Working with a Framework
  2. Discipline
  3. Problem Solving
  4. Presentation
  5. Use of Tools

However, rather than replacing these traditional skills, you will add to them in agile PM.   Here are five skill areas you will need to develop.

  1. Strategic Thinking
  2. Flexibility
  3. Transparency
  4. Facilitation
  5. Learning the Agile Framework

As a final exercise, in order to have this be the beginning point of a journey, rather than just an interesting stop along the way, Jeanine and Jeff suggested that we all rate the 10 skills above, both traditional and agile, according to how satisfied you are with your development.    You can either rate each one individually from 1 to 10 (with 10 meaning “highly satisfied”), or do I like I did, where you rate you each of the skills collectively.   For example, I was highly satisfied with my presentation skills do due to my five years of experience in Toastmasters.    I was least satisfied with my discipline skills as I am constantly struggling to get more organized.

Once you do the exercise, then take one or two areas from the list (usually the skills you are least satisfied with and pick at least one action item you want to work on for each area.   Or if you are very motivated, pick an action item for each of the 10 skills, but then prioritize these.


The German psychoanalyst Karlfried Graf-Durkheim once said, “if you are on a journey, and the end seems to be getting farther and farther away from you, then at some point, you realize that the end is the journey.”   In going towards the agile end of the continuum, your goal is not to arrive, but to navigate the journey.   I certainly felt that the presentation by Jeanine Izzo and Jeff Singleton ended up being an extremely helpful guide on that journey.   I can certainly recommend that you get in touch with them so that they can help you on your journey as well.

Agile Contracts Types–Part II

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.

This concludes my survey of the three processes listed in the Initiate Process Group and the Value-Driven Delivery knowledge area.   The next post will cover those processes in the Initiate Process Group that fall under the third knowledge area, “Adaptive Planning”.

Agile Contract Types–Part 1

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed properties that all agile contracts share.   In this post, I do a recap of traditional project management contracts in order to give a context for how agile contracts differ.

Here are the elements of the Agile Manifesto as created in 2001 by the Agile Alliance:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Note that the word “over” appears in every element of the manifesto.   The one relevant to agile contracts, of course, is element #3, “customer collaboration over contract negotiation.”   This means that contract negotiation is necessary, but that the priority needs to be placed on customer collaboration.   Why?   The creation of a contract in and of itself does not add value from an agile standpoint; the value is created in the customer collaboration and the contract is a mere formalization of this collaboration.

The agile contract acts as a type of risk management response.   What happens if things do not go as smoothly as the customer and the company doing the project envision at the beginning?   In a way, by making sure that there are contingencies for those possible future events (i.e., the risks), you can make sure that the team is spending all of its energy on creating value for the customer in the present moment.

Before I discuss the three types of agile contracts, let me review the three types of contracts used in the traditional project management environment.

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

Fixed Price Contracts in Traditional PM

These three differ with regards to how they answer the question:   who bears the greater share of the cost risk?    Let me explain first what the cost risk is before we explore this question.   The seller creates a product for the seller.   The amount of money it costs the seller to create the product is the “cost”, and the seller adds to the cost the amount of profit the seller wants to make, called the “fee”.   The “cost” and the “fee” together make what the buyer will pay the seller, namely, the “price” of the product.   In a fixed-price contract, if the “actual cost” of the product is higher than the “target cost”, the seller will pay the “target price” no matter what.   This means that, as the actual cost goes up, it eats into the fee or profit margin of the seller, and if it goes too high, i.e., higher than the target price, then the seller will actually lose money.   This is why the fixed-price contracts favors the buyer in terms of cost risk.

Cost-Reimbursable Contracts in Traditional PM

Let’s skip to the third type, cost reimbursable.   In this case, the buyer guarantees to pay the target price, no matter what the target cost is.   This is obviously favoring the seller rather than the buyer in terms of cost risk.   There are ways to balance the cost risk by using devices such as a “ceiling price” or a “cost incentive fee”, which I won’t go into here.   But traditional project management acknowledges that the cost risk favors one side or the other, and adjustments can be made to the basic two contracts type of “fixed price” and “cost reimbursable” to address that imbalance.

Time & Material Contracts in Traditional PM

The second type of contract has a cost risk which in some ways favors the buyer and in some ways favors the seller, and that’s why I put it in between the other types which clearly favor one side or the other.   When I was working for a Japanese manufacturer doing litigation management, our company would hire lawyers to help defend the company in the case of a lawsuit.   They were paid on a per-hour basis, with the fee depending on the experience of the attorney.

This is a typical example of a time & material contract.   We paid for the services of a person who worked for us on a per-hour basis.   How does such a contract favor the buyer (our company)?   The fee structure would not change during the duration of the case, so there was an element of predictability about it.   On the other hand, the fact that the number of hours worked by the lawyer was not fixed favored the seller (the law firm the lawyer belonged to).

So 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

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.

With that background regarding the three types of contracts in traditional project management, let us turn in the next post to the three types of contracts in agile project management.

Agile Project Management Processes Grid–Process 2.3 Contracts

The second chapter of John Stenbeck’s book, “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, contains an Agile Project Management Processes Grid, and process 2.3 is the third process in the second knowledge area called “Value-Driven Delivery.”    This knowledge area covers for agile project management the equivalent of both scope management and quality control portion of quality management in the traditional project management framework.   The quality assurance portion of quality management is covered in the “Continuous Improvement” knowledge area, the last of the seven knowledge areas in the Agile PM Processes Grid.

Contracts and Agile PM–The Fundamental Disconnect

There is a fundamental tension between the idea of agile, which tries to minimize formal documentation, and the idea of a contract, which is the ultimate form of formal documentation.    Unless you are an attorney, creating a contract is not a value-driven process.   It is the formalization of the agreement between your company and the customer, which is a result of a conversation that is, in fact, creating value.

However, it is necessary, and therefore, the way to create value with a contract is to a) make sure it accurately reflects the agreement reached in conversation with the customer (where the value is actually created), and to b) minimize the time spent negotiating and creating them.

4 Elements of Contract Suitability

Given the above, what  elements can be used to determine whether a contract is suitable for an agile project?

  1. Project objectives–it should include the elevator statement and product vision, as well as the project data sheet
  2. Roles and Responsibilities–the agile process should be defined, as well as the Product Owner and any other key team roles, with a clear statement of their roles and responsibilities
  3. Scope delivery–the method of scope delivery (i.e., backlog grooming) is specified, as well as go/no-go checkpoints;
    and a clause is included for cancelling for convenience at the end of iteration by either party
  4. Risks and rewards–cost responsibilities are shared using a target cost principle (where both parties bear the excess cost of changes beyond the target cost); clauses are added for a bonus, penalty, early determination and/or late delivery.


In general, an agile contract divides shared risk between the parties and defines the trust points between the parties.  It helps avoid problems related to unrealistic promises or demands, or poorly defined functional expectations.   It must be created in the spirit of win-win, rather than “I win, you lose.”   Properly created, it is a springboard for mutual creativity between the parties, not a prison that keeps it from thriving.

There are three possible types of agile contracts

  • Agile Iteration Contracts
  • Time and Materials Contracts
  • Phased Development Contracts

which will be compared and contrasted in the next post.

Agile Project Management Processes Grid–Process 2.2 Business Case

In John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference,” he creates an Agile Project Management Processes Grid, and in this series of posts I am covering those in the Initiating Process Group, and the Value-Driven Delivery knowledge area.

To my mind, “Value-Driven Delivery” in Agile covers some of the same ground as “Scope Management” and the quality control aspects of “Quality Management” (quality assurance aspects are covered in the “Continuous Improvement” knowledge area in agile).

Business Case–Definition

It is a written document that explains how the use of the company’s resources is aligned with the creation of the product, service or result that will be created by the project, and that the benefits to the company for doing the project will outweigh any costs and risks.

In other words, it ties together three elements:    the product, the business need (the reason why the customer wants the project done), and the strategic objective of the company (the reason why the company wants the project done).   If the business need goes away, then the project will go away as well.   If the strategic objective of the company goes away, then the project will go away as well.

Business Case–Acceptance Criteria

What are the criteria for accepting or rejecting the business case?   It should accomplish the following:

  1.  Provide context and background of the business environment and need.
  2. Outline options for meeting those needs, and recommending a solution
  3. Defining success metrics for the proposed solution
  4. Analyze the related cost/benefit and financial ratios
  5. Present a compelling case for change that secures executive support
  6. Secure executive approval

The business case should include a business model snapshot, a visual picture that helps illustrate some of the criteria above.   It should include the following elements:

  1. Critical success factors and goals (related to criterion #3 “Defining success metrics” above)
  2. Process maps of the current and future processes (related to criterion #5 “Present a compelling case for change” above)
  3. Opportunities for process improvement (also related to criterion #5)

The process maps listed as element #2 of the business model snapshot should include the following:

  • Roles and responsibilities for the various processes
  • Business rules that affect the various processes
  • Workflow diagrams that show how work gets passed from one process to another

The process map is a high-level visual picture of the major process steps broken down to individual sub-processes if necessary.   It helps improve understanding of business processes by breaking them down into simple visual steps.   This helps identify problem areas such as bottlenecks, processes that do not add value, and gaps where processes could be added that do create value.   It needs to be accurate in terms of its details, but nevertheless easy to red and understand.

Detailing the Solution

Criterion #2 for a successful business case is recommending a solution for meeting the business need described in criterion #1.   This solution is clarified by

  1. Identifying the stakeholders who will be impacted by the solution
  2. Identifying the business systems and processes that will be impacted by the solution (the “process map” is helpful here).

If these elements are present in a business case, it will help make the case to the customer that your company is the right one to do the project, and it will make the case to management that this project is the right one for the company.

The next post is on Process 2.3 “Contracts”.

Getting Things Done–The Agile Way

Based on Brian Tracy’s Goals program, I have used a planning journal to write down my main inspirational goals each year, and then to break down those goals into monthly and weekly goals.

For about a year, I took Brian Tracy’s recommendation to the next level, and wrote down my daily goals.    I found that doing this took about half ah hour, and he recommended doing it the night before rather than the morning of each day.   Here’s the practical problems I found with this approach.

First of all, I was often tired and doing a detailed laundry list of everything I had to do, and then prioritizing each item and putting them in a schedule was often mentally tiring.   However, saving it to the next morning when I had the physical energy wasn’t the best option either because I would have the physical presence of mind before my first cup of coffee to be able to do the daily plan.    And sometimes deciding what time I would have to get up would depend on what was in the daily plan, particularly if it was a weekend day.    Could I sleep in until late, or did I have to get up early?

The second problem was that the best laid plans of mice and men often go astray–sometimes even by the time I get to work.    One of the first things I do is check my phone-mail messages and e-mail message, and an urgent message from either one of those channels might alter my daily plan considerably.

It wasn’t until I got the work Getting Things Done by David Allen that I got a better, more flexible way of organizing my time.  And it wasn’t until recently when I started studying Agile project management that I understood why it worked better.   That discussion is the subject of today’s post.

Getting Things Done

In David Allen’s system, he recommends taking larger, aspirational goals and breaking down them down, just like Brian Tracy recommends.    However, he recommends stopping at the level of the weekly plan.     Let’s say on Sunday you draw up a weekly list of what needs to get done in the various areas of your life.    What do you do on Monday morning (or Sunday evening, the night before)?    You draw from that weekly plan those elements that you are going to aspire to get done during that day, based on urgency (how quickly it needs to get done) and priority (how important it is to get done).

This worked out a lot better.    Every day I would choose 10 items that I wanted to get done, and I would focus in on that list.    Yes, there were times that I would get an urgent message via telephone or e-mail, and have to add an item to the list.    But adding one item to a list of ten is a LOT easier than having to scrap an entire daily plan.    I figured that, at a minimum, I was saving 3 hours a week by not having to draw up daily plans.    The daily list would take 5 minutes at the most.    And at the end of each day, those items that I got done on my daily list would get checked off on the weekly plan and voila, by the end of that week I would have most of the weekly plan accomplished.    It was thorough enough to capture everything that needed to get done, but flexible enough to accommodate the changing circumstances that come from …. well, life itself.

The Agile Way

In preparing the material from chapter 2 “Introducing Agile Project Management” of John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference”, I suddenly got why the David Allen system was an improvement on Brian Tracy’s goal program.

The larger yearly or monthly plan was the roadmap that listed my aspirational goals over a long period of time.   From this, I derived the weekly plan, which was like a release plan in agile PM language, that I would use to capture all of the deliverables I wanted to complete by the end of the week.    The iteration plan was the daily list I would draw that would draw from the release plan or weekly plan those elements I wanted to complete during that day.    I would focus all of my energy on that iteration plan or sprint and not be concerned about the totality of the weekly plan.    That would improve my focus and keep me from being overwhelmed at the number of items to be done on the weekly plan.

The David Allen system is an agile version of the more traditional system that Brian Tracy advocates.    The breakdown process is the same, but the David Allen does not try to completely describe the exact scope for each day–life is too chaotic to be hemmed in by such a rigid system.

Now when I do my daily list I even call it “today’s sprint” to honor my newfound understanding that I am, in reality, using agile project management not just in my profession, but in making my daily life run more smoothly.

Agile PM Processes Grid–The Initiating Process Group and the Value-Driven Delivery Knowledge Area

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first block of processes, those in the first process group (the Initiate process group) and the first knowledge area (External Stakeholders Engagement).

Now, I am embarking on a description of the second block of processes, those in the first process group (the Initiate process group) and the second knowledge area (Value-Driven Delivery).

These three processes are as follows:

Process 2.1 Value Analysis
Process 2.2 Business Case
Process 2.3 Contracts

The next post was going to cover the first of these three processes, Value Analysis.   However, this process seems to be missing in John Stenbeck’s textbook.    I assume he is talking about Business Analysis in the agile PM context, but I want to contact him and make sure that is what he is referring to.