Parking Lot diagrams are a great way of summarizing an entire project’s progress and status onto a single page. They illustrate work done, work in progress, work planned and identify what is behind schedule.
 
In this example we can see that “Stock Search” in red, is behind, it was due to finish in November. “Create New Order” shown in green is complete, the boxes in yellow are ‘in progress’ and those in white have not been started yet. I have posted previously about their use and examples of how to produce them.

However, they miss an important element, the relative sizes (usually in terms of effort, but could be cost or risk) of the functional areas. So, in the example above, the fact that “Enter Order Details” might be 3 times the development effort of “Create New Order” is likely lost on the stakeholders reviewing the chart. Sure they can look at the number of features 15 vs 5 and likely surmise “Enter Order Details” is more work, but upon first impression, this is not immediately apparent.

So, bring on Scaled Progress charts, the box size represents estimated development effort. I have been using these with my current Steering Committee for a while. I meet some of these people infrequently and these charts provide a nice reminder of the overall project scope and where the project progress right now.

I attended the Agile Business Conference in London this week and presented on Tracking Project Performance. I missed this conference last year and so it was especially good to catch up with people again and hear what they have been doing. Also, after working in London for six years, but then living in Canada for the last nine years, it is always interesting to see how things have changed since my last visit. This year it was video screens replacing all the paper billboards going up and down the escalators on the Underground that caught my eye.

 

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

For the attendees of my recent Las Vegas course, below is a link to the PMBOK v4 to Agile mappings we discussed. My previous course material mappings were based on PMBOK v3, and before that the 2000 edition, which are out of date now.

 

Quite a lot changed from the PMBOK v3 to v4; all the processes were renamed into the new verb-noun format. Six of the old processes were merged into four new ones, two processes were deleted, and two new ones added. So it seemed like time to redo the mappings and post them online this time.

 

Cautions

Process guidelines and templates are not an acceptable replacement for common sense, thought, dialog, or collaboration. A fool with a tool is still a fool, but can be especially dangerous since they give the impression that they have a potential solution to tricky problems. Beware of simply following any project guidelines that seem counter to your objectives.

 

So, why would you want to be mapping the PMBOK v4 to Agile techniques anyway?...

IQ (Intelligence Quotient) and IQ tests that attempt to measure intelligence are well known. However, IQ is not a good predictor of how successful you will be in life, or how effective and valued you will be at work.

Emotional Intelligence (EI), often measured as an Emotional Intelligence Quotient (EQ), is a different measure that describes the ability to identify, assess, and manage the emotions of one's self, of others, and of groups.

“Research shows convincingly that EQ is more important than IQ in almost every role and many times more important in leadership roles. This finding is accentuated as we move from the control philosophy of the industrial age to an empowering release philosophy of the knowledge worker age.” - Stephen Covey

So since software is a knowledge worker activity, and agile methods promote an empowering release philosophy, for leaders of agile projects EQ is of special importance. How can we measure our EQ? Well Martyn Newman’s Emotional Capital Inventory (ECI) is a great place to start. This online assessment scores participants against the 10 EQ dimensions of:

1. Self-Awareness
2. Self-Confidence
3. Self-Reliance
4. Self-Actualization
5. Assertiveness
6. Relationships Skills
7. Empathy
8. Self-Control
9. Flexibility
10. Optimism

LeadingAnswers.com readers are invited to take the short version of the assessment for free, just follow this link. Free Emotional Capital Inventory Test.

I recently read an early release copy of Martyn Newman’s “Emotional Capitalists: The New Leaders” book and was impressed. Several years ago I finally realized that successful projects are more about people and less about processes and tools. A Computer Science degree and 20 years of technical experience had not equipped me for the role of managing teams. Since then my studies have been focussed on the higher leverage area of people and team dynamics more than project management mechanics. You definitely need the mechanics to run projects, but usually the final outcome comes down to people.

Reuven Bar-On was amongst the pioneers to write about Emotional Intelligence and Daniel Goleman helped bring the subject to the business world with his Emotional Intelligence best seller. I liked these books and agreed with all the points raised, but often finished a book without a clear action plan for what I should start doing differently tomorrow.

What I like best about Emotional Capitalists is the practical nature of the advice given. Not only are the concepts explained clearly with entertaining stories, but each chapter is followed with a one page action plan summary, the advice is very accessible whereas some other books on EQ are more theoretical.

 

Bad News and Good News
The bad news is your IQ peaks in your teens and from there on declines. The good news is that IQ is not a great predictor of happiness or success anyway, EQ is a better predictor of these, and EQ peaks in your late forties and early fifties so we have more time to practice and improve.

(As an aside, I think it is interesting how in our optimism we gravitate towards metrics that suit our circumstances. We are getting older and not any smarter, but hey, that’s OK, here’s a different score that we look better against! Maybe this is being wiser rather than smarter. Since turning forty my chances of running a sub 3hr marathon or sub 36 minute 10K again have approached zero, however I now use Age Weighted Scores and, problem solved, I’m not getting slower (well I am) but I can now compare my times against others my own age and use that as a metric for performance.) 

Anyway, have a look at the assessment, if nothing else it will familiarize you with some aspects of Emotional Intelligence that are critical to being successful today. Thanks again to Martyn Newman for giving a free trial of the tool for readers of this blog. The book covers many great topics that I plan to write on in the future, but for now I will end with some of my favourite quotes:

"You can’t lead a cavalry charge if you think you look funny on a horse" - John Peters

“Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others" - Jack Welch

"What lies before us and what lies behind us are small matters compared to what lies within us. And when we bring what is within out into the world, miracles happen" - Henry David Thoreau

"To be independent of public opinion is the first formal condition of achieving anything great" - Friedrich Hegel

“Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstance” - Bruce Barton

"If leadership is ultimately the art of accomplishing extraordinary things with ordinary people then building emotional capital is how you achieve it" – Martyn Newman

What defines project success? On “time and budget”, or “to specification and quality requirements”, maybe all of these? No, we are missing some less tangible, but critical components; how do people feel about the project once it is done.

On May 12 the PMI-SAC Awards for the best projects and the best project managers will be held in Calgary and Captain James Lovell, Commander of Apollo 13 will be giving the keynote “Apollo 13 – A Successful Failure”. This year I am a judge for the awards ceremony and in reviewing the applicants I have been thinking about what constitutes a successful project which prompted the recollection of some famous projects...

Apollo 13
Let’s consider Apollo 13. The third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from Lovell (that is widely misquoted as, "Houston, we have a problem".)

The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing future missions. “A Successful Failure”

Titanic
(The 1997 film not the original ship). This film was six months late, massively over budget and finished with a bloated 194-minute running time. Seemingly not a good performance given the original schedule, budget and scope requirements. Yet the film turned into an enormous critical and commercial success, winning eleven Academy Awards, including Best Picture and became the highest-grossing film of all time.

 

All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing. For some projects these requirements warrant extensive work and for other project domains a quick check through may be sufficient. As a minimum, the following list can be a helpful reminder to ensure you have covered the basics.  Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.

The list is also available at the bottom of the article as a one-page PDF document. While it is easy to make the list longer by adding more items, I would really like to hear how to make the list better while keeping it on one page (and readable) to share with other visitors here.

Security
  • Login requirements - access levels, CRUD levels
  • Password requirements - length, special characters, expiry, recycling policies
  • Inactivity timeouts – durations, actions

Audit
  • Audited elements – what business elements will be audited?
  • Audited fields – which data fields will be audited?
  • Audit file characteristics - before image, after image, user and time stamp, etc

Next week I’ll be teaching a two day Agile Project Management course for the PMI in New Orleans. The class sold out quickly; I only teach 3 or 4 times a year for the PMI and I wondered if registration numbers would be down this year. The fact that it filled up so quickly is very positive and perhaps more people are tuning to agile as a way to get more work done with less budget.

This year’s Agile Business Conference in London has the theme of “Driving Success in Adversity” and I have submitted a presentation outline and plan to attend. There submission system states “This year we invite presentations and tutorials emphasising how Agile practices promote efficiency in project delivery, guarantee business value and optimise return on investment.” This seems a great theme, agile is all about maximizing business value, and I am looking forward to the conference.
 
Meanwhile, in New Orleans next week, I am keen to hear how organizations are currently using agile methods within their organizations to add value. (I am also looking forward to sampling the food and feeling some warmer weather after a long Canadian winter!)

I recently wrote a post on Velocity Signature Analysis and have been looking at how undertaking large chunks of work as a complete team impacts velocity. We are currently three quarters of the way through a major (4 months long) piece of functionality and velocity is finally rising. This seems a pattern; for the early portion of a new area of work we spend a lot of time understanding the business domain and checking our interpretation using mock-ups and discussions. Velocity, in terms of functionality built and approved by the business is down during this time since many of the team members are involved in understanding the new business area rather than cranking out code.

As project manager I can get jittery, did we estimate this section of work correctly? Our average velocity for the last module was 60 points per month and now we are only getting 20! Weeks and weeks go by as whiteboards get filled, designs get changed, but the tested story counts hardly moves. Compounding this Discovery Drain phenomenon is the Clean-up Drain pattern. During the early portions of a new phase, fixing up the niggling issues hanging over from the last phase seems to take a long time. This makes perfect sense, if they were easy they would probably have been done earlier. It is always the difficult to reproduce bug, the change request that necessitates a rework of established workflow or multiple stakeholder collaboration that seem to bleed into the next development phase. While there may only be 3 or 4 bugs or change requests hanging over, they take a disproportionate amount of time to resolve.

I have written a couple of posts now (here and here) about the new PMBOK v4 guide due out soon. One of the new graphs included helps describe how project characteristics change over the project life time.
 

The top blue line of the graph is used to illustrate how Stakeholder Influence, Risk and Uncertainty start off high and then reduce as the project progresses. The Escalating orange line illustrates how the Cost of Changes increase dramatically over the project timeline.

Quite a lot has already been written on flattening the Cost of Change curve within agile, so I will leave that for now and focus first on the top line.

Before discussing ideas such as how ongoing business input in, for example, prioritization of the remaining work prolongs their ability to influence the project, we should take a moment to understand the PMBOK audience. The PMBOK is not just for software projects, or IT projects, it is an industry agnostic guide relevant to construction, engineering, and manufacturing among other disciplines.

As a general guide, I think these curves make sense, especially outside of software projects. The ability to influence does decline rapidly once designs are committed and construction begins. Likewise, Risks and Uncertainty also reduce generally later in the project once technical obstacles have been overcome.

Software though is different, actually I would hazard a guess that every industry is different really, however software is the one that I know about. Software exhibits a characteristic known as “Extreme Modifiability” meaning we can make many changes, even late in the lifecycle and still be successful. While it would be difficult to move a bridge 3 miles upstream when it was 75% complete; we could choose to move validation logic from the presentation layer, to a middle tier, or a database trigger late into a project.

Most agile projects track their velocity. For the past 10 years or so I have been studying the velocity profiles of my projects and any other projects I can get data from. Velocity profiles tell a story about the project, and like signatures are unique.

Tracking stories, or more normally points completed per iteration, gives the classic velocity graphs such as the one shown below.

Here we can see the Projected Velocity shown by the dotted blue line and the Actual Velocity shown in dark blue.

From observing 15-20 projects I have noticed the following reoccurring patterns. Am I the only one, or are these common?
 

“S Curves” are great to track project spend. They are simple to interpret and quickly let us see if we are over or under budget.

  

However, we could be doing fine spend wise, but behind from a schedule perspective. This is where Tracking Gantt charts come in and show schedule.

 

Yet, Gantt charts lack the spend component. Pretty soon most projects get ahead or behind in spend and time and so trying to gauge the overall project health becomes difficult.

This is why Earned Value Analysis (EVA) and Earned Value Management (EVM) were created, combining both spend and progress variables to produce a comprehensive set of project measures and metrics. However, there begins the problem.

What’s Bad about Earned Value

EVA is beyond most project stakeholders -

Most people who are not using EVM every week do not understand the terms. “Is a negative Schedule Variance good or bad?”, “What’s the difference between BCWP and EV?” (Answers: it is bad, and they are the same). Despite its usefulness, the confusing terms and heavy use of math puts off a large percentage of the population.

Debates digress beyond numerical accuracy - More challenging still is when several people do understand EVM and start debating which versions of the formulae to use and everyone starts obsessing on the math instead of the project. “Should we use EAC = BAC/CPI, or EAC = AC + ETC, or EAC = AC + [(BAC-EV)/CPI ?” Geez people, the developers probably pulled half of these estimates out of the air and we are applying advanced math to them?

What’s the value in tracking progress against a flawed plan? - EVM compares actual project performance to planned performance at a point in time. So, if our initial plan is wrong we could be effectively trying to do the equivalent of tracking our progress on a road trip from Calgary to Salt Lake City on a map of France! The quality of the baseline plan is a critical success factor of EVM. In agile projects we acknowledge initial plans will likely need changing and so the basis for effective EVM is quickly eroded with evolving plans.

Where’s the Quality?  - We could be on time and on budget, but building a horrible product that the business does not like or is low in quality. We should be aware that cost and schedule are not the whole picture. EVM and agile alternatives are just a part of the picture.

What’s Good about Earned value

It is a Leading Indicator - Perfect rear vision is not of much use to people. At least EVM tries to predict completion dates and final costs. Imperfect leading metrics are always more valuable than perfect trailing metrics, since they give us options to re-plan and change our approach.

It is visual - It is easy to forget the EVM graphs and focus on the numbers, but at the heart of the process are some useful graphs. Visual is good because it engages the right-side of the brain and helps us draw on more mental power to understand, interpret and plan appropriate responses. Visual things are also better to discuss and collaborate on since we can point, annotate and extrapolate easier than with words or numbers.

Agile Alternatives
So how can we maintain the Leading and visual components of EVM and reduce some of the down sides? Well "Double S Curves" are a good start.

 
 
In this graph we have a familiar spend line shown in green tracking to the dollar scale on the right hand axis; and also a feature based line shown in blue tracking against the points scale on the left. 

The gradient of the blue line indicates project velocity. Where it rises steeply we got a lot of points developed in a short time, where it is flat, progress was slow.

 

Adding a background on the graph can be useful to show functional areas. Here we can see that the “Configuration” and “Stock” components of the system have been built and we are currently in the “Sales” piece of functionality at just over 1000 points worth of functionality completed.

Also, at the end of 2007 the step in the background image shows where the scope of the “Sales” portion of the system was increased, shifting the remaining functional areas out by the new work amount. Yet we are still missing projections and a sense of if we are ahead or behind from both spend and schedule perspectives. This is where predicted values come in.

  

Now we can see how we are comparing against our projections. In this example we are overspent and a little ahead of progress currently, but the trends in velocity do not correlate with the continuing velocity improvements predicted.

As a replacement for Earned Value Management, these graphs are all you need. We can get the same metrics and indices right here.

 

Traditional EVM metrics like Schedule Performance Index (SPI) and Cost Performance Index (CPI) can be easily translated into Agile terms. For example, if we planned to complete 30 stories this iteration, but only completed 25 then our SPI is 25/30 or 0.83 (we are working at only 83% of the rate planned). Likewise, CPI is the Earned Value (Completed Features Value) to date divided by the Actual Costs to date, in the example above $2.2M / $2.8M = 0.79. This means we are only getting 79 cents on the dollar compared to what we had predicted, (but of course, who is to say what we predicted is correct.)

Cruel Irony
I find it ironic and amusing that “Earned Value” is a traditional project management term and agile projects often track progress in nebulous “Points”. This is backwards. Agile projects deliberately relate things back to real business value, and yet many traditional project track progress against tasks that add little or no business value and call the process “Earned Value”.

Creating a detailed requirements document that formalizes an incomplete, premature view of requirements that should change as details emerge and business continues to evolve is not earning much value at all. Yet prioritizing features by business value and tracking progress against the business oriented features is an excellent example of real “Earned Value”.

Next Steps
I have uploaded the example spreadsheet used to produce these graphs so you can get started with your own if you are intersted. The Excel “tricks” are as follows:

1) To get the two graphs on the same chart use the ‘Line – Column on 2 axes” graph option. This is on the “Custom Graphs” tab in old versions of Excel, In the Vista version of Excel, add a secondary axis to a normal line graph, by Formatting the data series, then click “Secondary Axis” on the Series Options tab.

2) Create a background image with bands that vary in height corresponding to their points estimates. E.G. a project with two phases one 300 points and one 200 points, would have background image with two bands, one, say, 3cm high the other 2 cm high. Just as long as the proportions are correct the image will be scaled to fit the graph region appropriately. I simply use PowerPoint to create my background images, but you can be as fancy as you like.

3) In Excel format the axes and adjust the Min. and Max values from 0 to you budget amount and points estimate for the project. If these number change, create a new background image and reset the scales.

Download graph_examples.xls

Tool support

I try to keep up with the agile PM tools, but as far as I know, Rally, VersionOne, Target Process, Mingle, XPlanner, etc do not produce these graphs yet. I hope they do soon and calculate the EVM numbers too. I talk to many organizations who want to apply EVM type analysis on agile projects or work with PMO’s that ask for these stats.

Discussion on when it is appropriate to use straight line extrapolation to calculate Estimates At Completion (EAC) and the impacts of updating plans will be the subject of a future post. In the mean time you can also read a research paper on the topic written for the 2006 Agile Conference.

Download rp2_cabri_griffiths_agile_and_earned_value_reporting.pdf

Local APLN member Edgardo Gonzalez, has kindly offered a Planning Poker card template for readers to download. (No longer are we tied to the decks generously given out by Mountain Goat Software at conferences; now we can print our own!)  Based on the Fibonacci sequence, these cards print on standard Avery stationery and can be used by team members to estimate story points. (Post on Agile Estimation Techniques)

Thanks Edgardo for your gift to the community.

Download Planning Poker Cards.doc

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.

(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity.  Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.

Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)

Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.

Customer: How much is that parrot in the window?
Pet shop owner: Somewhere between $200 and $250
Customer: Erm, OK, I’ll give you $200 for it then!

To some people providing estimates as a range of values seem a strange and unsatisfying way of conducting business. They just want to know how much something will cost, not how much it may or not cost. This is reasonable if the object or service is ready for use, but not if it has yet to be created. The more uncertainty involved in the process the more likely there will be some variability. Now consider this conversation:

Customer: How much will it cost for a taxi ride from the library to the airport
Taxi driver: Probably between $20 and $25, depending on traffic
Customer: OK, that sounds fair, let’s go

It seems more reasonable, we understand the variability of traffic. Unfortunately not all stakeholders understand the variability caused by evolving requirements and changing technology often associated with software projects. However the uncertainties of software development are real and we have an obligation to report estimates as ranges to help manage expectations.

In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.

Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.

Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)

Parametric
• Function Points
• Use Case Points
• Object Points

Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.

Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.

If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.

Risk Management processes may have the air of a traditional, process-driven project management activity. However, agile methods are great risk reduction vehicles, and are actually very well aligned for rapid risk identification and reduction.

What is a Risk?
A risk is some event or circumstance that could transpire and impact the project. The PMBOK talks about good risks (opportunities), but most risk literature focuses on events with potential for negative impacts (project risks).

The risk management process outlined in the PMBOK is shown below:

Where’s the “Risk Response Doing” Step?
One step absent from this process is a “Risk Response Doing” step that focuses on executing the actions identified in the risk mitigation plan. In the defense of the PMBOK, these activities get moved to the project plan and scheduled with the regular work activities.

However the apparent lack of a doing step mirrors a problem seen on many projects. Namely, that risk management is undertaken as a separate (sometimes once only) passive activity that does not drive enough action on the project to prevent the risk happening. As a result we see risks occurring and can point to the risk list to where it was identified, yet not enough was done to prevent it happening.

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

I spend a fair portion of my time working with Project Management Office (PMO) and Project Support Office (PSO) groups helping them integrate agile methods. One simple concept I’d like to outline today is the idea of Agile Interfaces.

Agile methods provide a great feature delivery engine, they iteratively feed on features from the backlog and produce tested functionality of high business value.

To external stakeholders this also represents a daunting and unfamiliar process to connect to. Its cyclical, seemingly never ending process is about as appealing to interact with as putting your arm in a washing machine while running. However there are a couple of friendly, safe interfaces that can alleviate mid-cycle arm twisting (how we normally extract information from the team.)

As mentioned, while agile methods focus on delivering features, they often do not provide the information required for PMOs, PSOs and other supporting groups. They typically do not encompass the entire enterprise lifecycle omitting important pre-project work and beyond delivery activities, as shown below.

If you have analysts working ahead of development, or have testers working significantly behind development, then you may have “Pipelining” problems.

Pipelining is the term used to describe the situation when business analysts are working ahead on the requirements for a future iteration; the development team is working on the current iteration, and the test team is engaged on a previous iteration.

In some circumstances analysis may be several iterations ahead and testing several iterations behind. To some people this may seem an efficient use of resources with each group running at their optimal speed, unfettered by the co-ordination constraints of different groups. However from an agile and lean perspective this is problem, a bad-smell that needs fixing.

Here are the problems with pipelining:

Three teams not one – in a project where pipelining is occurring we do not have one cohesive team we have three teams (or more). It is hard enough co-ordinating the members of one team towards a common goal aligned to business benefits. When there are three teams it is just too easy for people to claim that they did their bit and problems lie with other groups. Yet, the fact remains that if the software does not meet business satisfaction then it is everyone’s problem.

Increased Work In Progress (WIP) – Requirements whether they are in the form of user stories, use cases, or formal specifications all represent work invested that has not delivered value to the business. The same goes for code, until this functionality has been tested to the satisfaction of the business it is not valuable. As the time increases between capturing the requirement and finishing the last test two problems occur. The first is classic accounting, money have been invested for no return yet and there is a risk associated with future returns. The second is that requirements decay; the longer we keep requirements around for, the higher the likelihood that they will no longer be required or will have to change.

Increased time from defect injection to defect remediation – the cost of change increases the longer a defect goes undetected. In a pipelining project, defects introduced by faulty analysis could take months to be detected in testing or user review. Fixing the problem after this period of time will entail refactoring far more code (for the work happening in the interim) than if it was detected earlier, and will increase technical debt...

(Chop those large projects down to size)

When I started out as a PM and had a few successful projects under my belt, I wanted to manage larger and larger projects. Now I’m looking for ways to make them smaller and limit the functionality initially tackled. This is not just laziness or a lack of ambition on my behalf, instead it is a realization that delivering business value comes from successful projects and that large projects are inherently risky and more likely to fail.

Jim Johnson of the Standish Group presented some interesting metrics at the PMI Global Congress conference in Toronto a couple of years ago that confirmed my suspicion. From a study of over 23,000 projects it was found that the success rate dropped as project duration increased.

From the graph we can see that most (over 50%) of the 6 month projects surveyed were deemed successful, dropping to 23% of 12 month projects, and less than 10% of 24 month projects. Now, we need to understand what “Sucess”  means here. The criteria was quite strict and defined as within 15% of cost and schedule and to customer defined functionality and quality standards.

I expect a large proportion of these “failed” projects merely missed the 15% cost or time criteria and the picture would not be so bad with a wider margin. Predicting costs over long periods is notoriously difficult as even labour rates and inflation predictions elude the best market ecconomists. However the trend is still true, larger projects carry a much higher probability of failure for a number of reasons we will see...

In my last post I suggested spending less time worrying about project metrics and more time on stakeholder concerns, so I thought a tool to simplify project tracking might be useful.

Having completed project estimating with the team, it is often necessary to convert effort estimates into cost estimates based on likely utilizations and then track actual hours billed against these projections. Today’s download is a simple burn-rate estimation tool that produces S-Curve graphs and let you track actual spend against burn-rate projections and planned budgets.

You can download the spreadsheet here:

Download estimation_and_budget_tracking.xls

Feature Driven Development (FDD) employs a smart way of rolling up development progress that provides an easily digested summary of project status using Parking Lot diagrams. Yet, their appreciation and use outside of FDD is quite rare. I taught an Agile Project Management class last week and nobody had seen or used them before, which is a shame because, especially for large projects, they are a great dashboard tool to illustrate overall progress and pain points.

Parking lot diagrams are not just for FDD projects, they can be used equally as well on XP, Scrum, or DSDM projects and this post will introduce them and provide you with a sample Excel spreadsheet for creating them.

As projects get larger the number of features (user stories) you likely have to manage increases. Small to medium size projects with a few hundred features can be managed fine with decks of cards, task boards, and burn-down charts, but as projects scale this information becomes hard to manage and difficult to digest by stakeholders. Parking Lot diagrams roll-up features into functional groups and then these groups into functional areas to better illustrate overall progress against business areas.

Let’s say we have 15 features associated with our order entry functionality. These features could be rolled-up under an Enter Order Details group and reported using a Parking Lot diagram as shown in the annotated example below.

There is a lot of information here. FDD promotes the idea of a chief programmer, an individual who is responsible for a piece of functionality. Their initials “FB” can be shown above the parking lot diagram. If a stakeholder has a question about this area, then they know (Fred Blogs) is the person to speak to. Alternatively, if you are working on an XP project with shared code ownership it may not be appropriate to display initials, in which case simply don’t. Inside the main box the feature group is named (Enter Order Details) and in brackets the number of individual features that make up this group or set is shown (in our case 15).

The colour of the box indicates status. With our colour scheme White for not started, Yellow for work in progress, Green for complete, and Red for late. Standards vary, some people use Blue for work in progress, Yellow for nearing the due date, and Red for late, but as long as all the project stakeholders agree on what each colour means you should be fine. The main box also contains a percent complete figure based upon the combined status of each of the (15) features within it.

The bottom portion of the box contains a progress bar that duplicates the percent complete figure to give a more visual measure of this number and the target completion month for this group of features.

The real power of this technique comes when these feature groups are combined into feature areas and an overall dashboard for the entire project is created.

So, you think you are an agile project manager? Or, you want to assess how agile your projects’ manager is? If so, try the following Agile Project Management Assessment Quiz.

Inspired by Guy Kawasaki’s Venture Capitalist Aptitude Test (VCAT) I thought it would be fun to create an Agile Project Management Assessment Quiz (APMAQ).

Answer the questions listed in the five categories below and total your scores for each category using the values listed in square brackets after the question. Remember, answer honestly, describing what you actually do, not what you would like to do!

On to the test...

Agile teams are picky when it comes to the adoption of high-tech tools. On the one hand they seem positively geeky in the adoption automated build and testing tools. Yet on the other, absolute “luddites”, spurning technology, when it comes to project scheduling and tracking tools; favouring cards and poster sized graphs over computer based tools.

Why the schizophrenia over tools? When you dig deeper behind the reasons for these choices, some interesting facts emerge. Rather than relying on Work Breakdown Structures and Gantt Charts it is more common to see agile projects tracking work and progress via Big Visible Charts and task boards to track projects.

Work Breakdown Structures and Gantt Charts have many technical advantages over cards and corkboards. They can illustrate very deep hierarchies of tasks, support task dependency integrity checks, and allow the calculation of interesting metrics like slack, sub-assembly costs, and resource utilization. Yet, therein lies part of the problem, and the principle reason agile methods avoid these techniques. The math, statistics and reports that can be produced with these tools belies the volatile nature of what is being analyzed: tasks and estimates.

When we use tools that perform scheduling calculations and forecasting two problems arise...

I recorded another podcast with Dina Scott of ControllingChaos recently. This one is about the problems of applying traditional Earned Value Analysis to Agile projects and then the promotion of some alternative, Agile metrics that answer the same questions.

The central theme comes down to questioning the logic of using conformance to a plan that is likely to be flawed as a yardstick for project assessment. Instead I suggest we can employ an extension to Cumulative Flow Diagrams that provide better project indicators.

The podcast can be found here and a link to my previous post on Agile Earned Value here.

Q: Does Earned Value work for software projects?
A: Absolutely, Earned Value Analysis (EVA) is a statically valid reporting approach that can be applied to any endeavour. It compares actual progress and spend against projected progress and spend.

Q: Can you use Earned Value on Agile projects?
A: You can, but I would not recommend it. There are fundamental problems using EVA on agile projects relating to baseline plan quality. Also there are better alternatives available for agile projects.

Earned Value analysis and reporting measures conformance and performance to a baselined plan. So, given that on agile projects we know that our initial plans are likely to change, why track progress against a weak plan?

Risk management is an important activity on both traditional and agile projects. This article will introduce a method for quickly visualizing the risk status of a project and identifying risk trends.

A widely accepted definition of a risk is:

“A discreet occurrence that may affect the project for good or bad”

However, I prefer the less comprehensive, but higher impact statement:

“Today’s risks could be tomorrow’s problems”

We need to actively attack risks before they become problems on the project. Unfortunately, all too often risk analysis and risk management steps are conducted alongside the regular project tasks rather than being drivers for work scheduling. Risk management plans and risk lists are created, but their findings do not influence task selection and scheduling, then risks occur and people identify the issue “Oh look, risk #4 occurred”, but the risk mitigation steps had never made it into the project plan.

Agile projects have many opportunities to actively attack the risks on a project before they can become tomorrow’s problems. Iterative development allows high risk work to be tackled early in the lifecycle. Features (or stories) that carry high risk can be undertaken in early iterations to prove technology and remove doubts. Carefully balancing the delivery of business value and risk reduction is a wise strategy for feature selection that I will write more on shortly. Until then how do we illustrate the risks on our projects to all stakeholders?

Cumulative Flow Diagrams (CFDs) are valuable tools for tracking and forecasting agile projects. Today we will look at creating CFDs and using them to gain insights into project issues, cycle times, and likely completion dates.

In Microsoft Excel a CFD can be created using the “Area Graph” option. The attached file “Example CFD.XLS” contains the data used to create the CFDs in this article, including the one shown below.


Figure 1 – Sample Cumulative Flow Diagram
Download cfd_example.xls

The software development industry has a poor track record for developing and employing effective software metrics. This is because most of the metrics selected are tangential to the true goal of software development - delivering business value, and instead focus on software attributes and accounting measures.

Metrics such as lines-of-code per developer week, function points created, hours worked, or budget consumed appear important measures, but they have dangerous and counterproductive implications. The use of these metrics reward the wrong behaviour, the phrase “you get what you measure”, highlights the problem. By tracking lines of code written, visible and unconscious incentives to generate lots of code are established. On the surface this may seem attractive, as a manger of a project it is gratifying to see lots of code being written, but what is really required is functionality completed, business value generated, and customers satisfied.

The more code generated the harder a system is to maintain and extend. With incentives like lines-of-code written, how do value-adding activities like refactoring simplifications appear? Reducing 20,000 lines of code to 15,000 is a good thing, but from the lines-of-code perspective it looks like the project is going backwards.