As we start 2010, the second decade of the 21st century, project managers really should be embracing 21st century technologies and approaches. While developers and other project members have been benefiting from improved communication and collaboration via new technology in the last 10 years, project managers have been slower to adopt them.

The plus side of being a late adopter is that most of the kinks get ironed out before you experience them and all the features you may need have probably already been developed. So, time to get with it. Perhaps it can be a New Year’s resolution to at least examine these tools and approaches if you are not already using them on your projects.

The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.

Also, project management is a largely individual activity, teams of developers and business analysts are far more common than teams of project managers, so peer-to-peer learning and tool support is almost nonexistent for project managers. Plus, project management can often be a reputation based market and to some people fumbling around as a beginner in a new approach is very uncomfortable to them. Well it is time to get over it, this is how we learn anything, and if you are concerned about looking foolish, just imagine how foolish you will look when everyone else has moved with recent trends and you are in the last stand of dinosaurs.

My last post was on modifying Parking Lot Diagrams to use the area of boxes to show the relative effort of differing parts of the system. The idea was that while traditional Parking Lot diagrams are a great way of summarizing progress at a project level, the customary approach of giving all the feature groups the same size box may lead people to believe these chunks of functionality are of equivalent size or complexity.

In the boxes below, the number in brackets describes the feature count, but this requires people to read the numbers and then consider the relative sizes. My goal was to create a new graphical summary that depicts the relative sizes via box area to make the summaries easier to understand.

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

In the second example we can quickly see the relative estimated sizes of the areas of work, with for example, “Enter Order Details” being three times the size (in area) of “Create New Order”. In this example to keep things simple, I am using feature count (15 vs 5) to depict effort and area. Most projects will use development effort in points or person days as the scaling factor.

Anyway, I have been using these scaled Parking Lot diagrams on my projects for a while, created quite laboriously in Excel and PowerPoint, and I was hoping that someone with better skills than I have could help me streamline the process. Well, in typical fashion, soon after posting I learned that:

A)    I may be asking the wrong question
B)    My invented solution has already been done before and far more elegantly
C)    It has been done on the Simpsons

Oh, the joy of the internet! Actually this is of course a great thing and now I can progress from a much firmer foundation, and far quicker than my slow evolution was taking me...

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?...

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!)

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.

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.

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

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.

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

I recently posted an entry on a risk assessment tool you can download and use. Risk management (or more precisely risk avoidance) is a critical topic, but one that is often dull to read about and therefore neglected. One of the few useful and entertaining books on the subject is “Waltzing with Bears: Managing Risk on Software Projects” by Tom Demarco, Timothy Lister, authors of the ever popular “Peopleware”. This post provides a useful summary of their top 5 software project risks.

While not an agile focussed book, I find it interesting that of the top five software project risks identified in Waltzing with Bears, all have suggested solutions rooted in agile methods. Demarco and Lister rate the top five risks and their mitigation strategies as...

This post introduces a useful risk assessment tool you can download and use on your projects. While I created the spreadsheet formatting and presentation, the risk categories, questions and scores come from IEEE analysis of actual software project risks, so they have a reputable source.

The Risk Assessment Challenge
A problem with risk assessments is that risks are often relative to the observer. What might seem like an acceptable risk to you might be unacceptable to me. For many organizations it is difficult to get an objective view of their project risks across a portfolio of projects because different project managers have different risk thresholds. What a “Gung-ho” project manager rates as a “Medium Risk” project might actually be “Very High Risk” project to the majority of other project managers. Even more problematic, is when project risk assessments miss major categories of risks and are rated much lower risk than they should be. The risk profile tool I will introduce is a mechanism to help bring consistent risk assessments across an organization and ensure no major risk areas are omitted.

Agile projects prioritize requirements based on business value. There may seem like no business value in the non-functional requirements of Compatibility, Usability, or Reliability, but if the systems fails to deliver one or more of these “~ilities” then the system is a dead-duck delivering no business value whatsoever. (We may design and build the highest specification car on the planet, but if it only runs on unicorn sweat, needs three hands to drive it, or manages only 5 seconds between break-downs it is not useful.)

So, given that we do need to prioritize non-functional development alongside functional requirements, what mechanism do we use? One approach that business folks understand uses money as the prime driver. A fancy descriptor for the technique might be “Feature prioritization based on balancing predicted ROI against expected monetary value of risk mitigation” but let’s just call it “Smart Planning” for simplicity.

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?