A few days ago I was in a daze as I waited in the line at Subway.  I was thinking about a dilemma my friend Phil had.  Phil is a project manager for a team that creates internet applications and web pages for a large company.

I spoke to Phil after my lunch ritual and the Subway analogy connected with him.  Today his team limits the work in progress, and they have “stopped starting and starting finishing” more enhancement requests than ever before.  They now have capacity to go beyond maintenance and pursue new projects that can provide high value to his company.

What a delicate subject to broach. I will be an objective observer and not assign any blame on the gulf spill until the details are available, but I would like to use this tragedy to discuss how it relates to project risk planning.  I am guessing that something was overlooked during the formal risk planning process related to the Deepwater Horizon oil rig drilling into the Gulf of Mexico.

I have been using agile project management methods for 10 years and have attended numerous agile training courses and conferences.  In all of my training and experiences I have never heard anyone discuss formal risk planning as it relates to an agile process.

If you take agile training you will hear folks like me say “agile is continuous risk management”.  This is a true statement.  We take risk out of the requirements by working face to face with the customer.  We take risk out of the build by continuously integrating the code.  We take out the risk of delivering buggy code, or code that goes beyond the need, by using Test Driven Development.  So if we are performing all of these practices do we really need to do any upfront work related to formal risk analysis and planning?  The answer is yes, sometimes it still makes a lot of sense to do formal risk planning.

If you are not familiar with formal risk planning, let me provide a high level synopsis.

First we sit down as a team – executives, managers, business folks, and technology folks.  We discuss everything that could go wrong with the project and create a list of potential risks.  Once the list is complete we talk about the impact if the risk materializes.  In figure 1 you can see an example of a risk assessment.  In this example we note that Risk ID # B1, “incomplete migration”, only scores a 1 on the impact scale, meaning if the risk materializes the impact will be minimal.

Figure 1

Continuing with our example, Risk ID # B5, “Insufficient resources”, is scored as a 5 on the impact scale, meaning if it happens we are in big trouble.  We probably will not be able to deliver any project value if this risk materializes.
Once the team identifies the impact of a risk, they move to the probability of the risk occurring.  If we stick with our previous two examples, Risk ID # B1 has a .25 (25%) chance of occurring.  Risk ID # B5 has a .75 (75%) chance of occurring.  Since B1 is low risk and low impact, we are going to accept it and not do any contingency planning.

Since B5 is high impact and high probability, we need to lay out our plan for managing this risk throughout the project.

As I mentioned at the start, this exercise makes sense on some agile projects.  I cannot provide specific criteria for you to use, but I can tell you what encourages me to do this exercise at the start of a project:

1) When I am working on a project with high dependency on groups outside of the project team.

2) When a sponsor or business owner has a history of delaying or cancelling projects due to disregard of project risks.

3) When the technical team sees numerous business risks that the business customer cannot see or envision.

4) When I am working on a CYA project.  Agile is all about collaboration and shared ownership, but on occasion you may find yourself managing a project where you need to CYA due to the political environment.

5) Projects with a long period of time for iteration zero work (iteration zero is work needed to establish a foundation before coding begins, such as ordering and installing servers, working through contracts with vendors, and obtaining help from teams outside of your control). In my experience this would be a project with an iteration zero longer than 3 weeks.

6) When the customer wants to.  If your customer enjoys this exercise and it makes them more comfortable on understanding the project risks, do it.

7) When an internal project management governance group requires this process.

8) Whenever you are using technology that has never been used by the team before. 

Use your knowledge and experience as a project manager to help the team determine when this exercise provides value.

Lastly, when you do use formal risk planning do not consider it a one-time event.  Find a regular day and time to update the risks and manage them throughout the project.

Please contact me if you would like a copy of my risk assessment template:  greg@gssolutionsgroup.com

In the recent film, Up in the Air, George Clooney’s character delivers a seminar that asks the question, “What’s in your backpack?”  George asks the attendees to envision they are going on a mountain hike, and to pack all of their belongings into a backpack. George has the attendees envision packing their cars, all of the furniture and knick knacks in their home, and then the home itself.  George concludes by asking attendees how full their backpacks are, and if they can still envision hiking the mountain with all of these items on their back.  George brings home his point at the end, pointing out that many of our possessions and legacy items hold us back from being effective and happy on our “daily hike”.

I personally do not want to give up my home, my car, knick knacks, or even my pets in real life, but I do agree with the “light backpack” perspective when it comes to project management.  Many times we carry too much baggage from our previous experiences, or from the overhead of our Project Management Lifecycle.  Let me provide an example.

Last year I worked as a project manager on the delivery of a new Content Management System.  The goal was to go live with the critical functionality in 4 months.  My goal was to work quickly with the team and the customer to identify the critical features and the key risks we needed to manage.

When I started packing my project manager backpack for this project, I wanted to put in an outline of the processes we needed to use, a high level schedule, a method for tracking daily progress, an environment for frequent communication and status sharing, and a method for demonstrating and adapting as the project proceeded.

My project is assessed to determine what practices I must use and which documents I must complete.

I was excited about this project when it started, and I felt confident in the tools I was going to put into my backpack.  Unfortunately my company had rules for what I had to put in.  I had to complete a Project Tier Assessment.  The assessment asked questions such as project cost, business unit impact, and external customer impact.  Based on my entries, the spreadsheet calculated a score, then summed the score by area to determine my tier.

Once my tier was assigned I was sent a spreadsheet with the required documents and processes the project had to follow.  Here are approximately ½ of the required documents and processes:

• Business Case
• Business Partner Identification Checklist
• Project Tier Assessment
• Executive Summary
• Technical addendum to Exec Summary
• Initiate Gateway Checklist
• Project Document Location Form
• Project Financial Control Tool
- Project Cost Estimation Worksheet
- Technical Assessment (Part 1)
- Technical Scoring Model Template
• Risk Assessment
• Business Needs Tool
• Business Needs Checklist
• Gap Analysis
• Resource Planning Tool
• Value Delivery System (VDS) Report Out
• Requirements Package
• Organizational Training Plan
• Plan Gateway Checklist
• Project Communication Plan
• Project Plan
• Project Schedule
• Project Status Report (Most recent)
• Issue Log
• Issue Escalation Reports (If applicable)
• Location Summary
• Resource Responsibility Matrix
• Resource Planning Tool
• Team Roster
• Design Integration Summary
• Implementation Plan
• Implementation Gateway Checklist
• Integrated Test Case
• Integrated Test Plan
• Integrated Test Results Report
• Project Change Requests (if appl.)
• Benefits Realization Gateway Checklist
• Post-Implementation Checklist
• Product Benefits Validation Form

As mentioned, this was about ½ of the required documents and processes.  How would you feel about carrying this backpack into your next project?  Not to mention that each of the required forms was very detailed, and required the signature of various executives.

In defense of my employer, the company had failed an audit many years earlier, which had lead to the new, beastly Project Management Lifecycle.  Regardless, most projects are about making or saving money.  The overhead required for this project would marginalize or nullify the anticipated benefits.

What should you do if factors beyond your control are requiring you to overload your backpack?  First ask this question – does every document and process have a customer?  If I do this, who will use it and what value will it provide?

When I say customer I am going beyond the end user or paying customer.  Customers can include internal oversight committees, external regulators, or even vendors.  The main point is to make sure you are not doing a step just because you were told to do it the day you started, or because “that’s the way we have always done it.”  Dig a little deeper when you cannot see the value of a step.

Second, push back when you find “no value” steps.  On the project above, I met with the Project Management Lifecycle team several times and asked to skip certain steps and documents when I could not find a customer.  Most of my requests were approved and I was allowed to skip many documents that did not add value to delivering a Content Management System.

In summary, it really isn’t about packing light or heavy, it is about packing at the correct level for a given project and it’s unique needs.

Hi, welcome to my Blog. My name is Greg Smith and today I am officially opening my blog.

As the title implies, the focus of my blog will be to shed light on how to create a solid software development process for your company, within the unique constraints and challenges you face.  I will be discussing agile principles and practices in this blog, but the main focus will be on how to be agile within your constraints and roadblocks.

This blog will answer questions such as “should I accept the constraint?”, “should I challenge the constraint?”, “have others negotiated and overcome this constraint?”

Greg Smith presents at the Agile 2009 conference.

I will also spend a lot of time on the areas that I feel are being neglected today.  For example, I believe there are as many people rolling out COTS (Commercial Off The Shelf) software as there are people creating code from scratch.  I think COTS needs to be discussed from an agile perspective and I intend to do so in the coming weeks.

I also believe agile discussions have mainly focused on software development, and we do not give teams enough information on how to integrate with all of the pieces and people that tie to the project.  Many departments and people are either providing inputs or receiving outputs from the project.  We need to discuss the software lifecycle in context to the big picture.

Another hot topic for me is what happens to classic project manager work in an agile project.  I have a lot of experience in this area and I hope to shed new insight and ideas into this area.

I welcome your feedback as the blog grows.  I have strong opinions based on my experiences, but I am still growing and learning, and I welcome your thoughts and feedback.

Thanks!  Greg