Delivering Value

Last week I was out on a client visit to do a couple days of product training. The customer was not only new to VersionOne but also new to Agile. The idea for the engagement was to blend product training with some targeted methodology training to see if we could get them jumpstarted and on their way.

It became pretty obvious by the middle of the first day that our original training plan was not going to suit their needs. While I was prepared to deliver exactly what they asked for, the training would not have delivered the value that they expected.

Had we followed the original training plan, I would have left the customer unable to effectively use our software.

Coming from a traditional project background, I am a firm believer that some degree of up front planning is essential. The problems start when we are so confident in our plans that we stop listening. When we stop listening, we stop learning. When we are unable to learn, we are unable to adapt.

I met with the customer and shared with them my observations. We discussed an alternative approach for our second day and agreed to take the training in a different direction. We came up with a new plan that better met their needs and put them in a much better position to be successful.

Did changing course introduce some risk? Absolutely. Change always introduces some risk and following the original agreement would have been the safer approach. By taking that risk we were able to generate greater value for both the customer and ultimately for VersionOne.

At the end of the day, isn't that what it is really all about?

Subscribe to this blog

Agile is Risk Management

There was a great question last week in the comments of one of my blog posts. The reader asked if agile offered any unique proposals for managing risk on a project? I've been blending my traditional background in project management with agile for several years now and sometimes I have to remind myself of what I've taken from what sources.

After reviewing the PMBOK section on Project Risk Management, I had to conclude that Agile doesn't really offer anything new. Surprised? The PMBOK has processes for developing a risk management plan, identifying risks, performing qualitative and quantitative analysis, conducting risk response planning, and monitoring and controlling risks.

You can clearly make the case the agile might take a lighter approach to risk management, maybe rely less on documentation, but fundamentally you are doing many of the same activities on an agile project as you might on a traditional project. Why are agile methodologies so good then at identifying and mitigating risk?

Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.

There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.

Many project managers take a boiler plate approach to risk management. They deal with the easy stuff, the obvious risks that could be assigned to almost every project. Are we going to run out of money? Are we going to lose a key contributor? What happens if the project is late? While these are all important, they only represent a small slice of the kinds of risk we need to consider.

As project managers, we tend to assume that the business vision is accurate. We assume that if we deliver to the spec we'll satisfy the market needs. We gloss over technical uncertainty because the technology guys are responsible for making all the code work. More detailed planning and designs do not mitigate risk. The only thing that really mitigates risk is delivering product.

Agile mitigates risk by building project frameworks that encourage frequent delivery, constant inspection and review, and allow us to adapt when things are not going as you expect.

In short, agile is risk management.

Subscribe to this blog

Agile Risk Management - Logistical Risk

This is the final installment of a three part series on Risk Management. Part one discussed how I think about business risk. Part two dealt with how to think about technical risk. This post will address some things to think about when considering logistical risk.

Logistical Risk

Logistical risk deals timing and team member availability. These are your people and money risks. Once the business risks are mitigated and we have proven there is a viable solution, this is where the team can really scale the project and build out the bulk of the solution. Here we are answering questions about having the people to do the work. We are monitoring to see if we are making the progress we expected at the beginning. Are we going to have to make any tradeoffs to hit our market date?

Logistical Risks deal with people. Do we have enough people to do the work and are our original assumptions about their capacity going to hold?

In reality, you are dealing with all three types of risk all through the project. The focus becomes logistical risk once you have tackled the other high risk areas of the project and are ready to get down to the business of building out the product. On a large team, you have probably broken your core team up to seed other small teams on the project. As the project scales, you are working to make sure the interactions between the teams are running smoothly. You are concerned with establishing a stable team velocity, grooming the backlog, and making sure that you are regularly delivering business value.

You are working to make sure that the team has everything it needs to be successful. You are actively removing impediments, and interacting with other parts of the business to prepare for your final product delivery. You are probably coordinating the availability of extended team members, managing external dependencies, and possibly dealing with unexpected departures. Logistical risk is about managing the team through the life of project execution.

In Conclusion

I have witnessed too many Project Managers dealing with risk as something external to the project. It is as if the project is on one track and risk management is on another. Risk management is not a separate process that lives outside the way we build software. Risk management needs to be built into the very fabric of the project itself.

Delivering product to customers mitigates all kinds of risk, let's do that a lot. Continuous integration mitigates risk, let's do that too. Continuous testing mitigates risk, let's test all the time. These are not things that the technical team just does, they are things that project managers need to make sure is happening. We need to make sure they are built into the foundation of our project management approach.

Subscribe to this blog

Agile Risk Management - Business Risk

As project managers, we must understand how to identify risk and how to put strategies in place to mitigate their effects. To put an effective strategy in place, it is necessary to consider what factors are leading to the risk and when these factors are most likely to impact your project. Over the next few posts we'll talk about three common categories of risk, how we distinguish them from each other, and what we can do to make sure they don't negatively impact our project.

Business Risk

Do we have reason to believe the features we've scheduled for the upcoming release will deliver the value we have planned? Do we have reason to believe the team can deliver that value within the time and cost constraints we have established? What about our customers, have they weighed in that we are building the right product? Is everyone on the team organized around a clearly articulated product vision? Answering these kinds of questions is what it means to mitigate business risk.

Business risk deals with value. In other words, can our project deliver the value we have promised to the business?

Business risk is one of the first kinds of risk to consider on a project. This is often addressed before the entire team really gets going on the project. In this stage, you are setting goals, chartering the project, and getting the project funded. Once the vision is set, make sure that the features you define in the product backlog are focused on delivering that vision. Weed out requirements that are not necessary to deliver that vision, keep things as simple as possible.

Establish a high level architectural approach for the product and use this common understanding as a baseline for estimating and planning. Estimate your backlog, keep it prioritized, and work on the highest value features first. Measure the throughput of the team and assess progress against your backlog. If your team's throughput is less than expected, deal with these issues immediately. Give your product owners the opportunity to adjust the scope of the release or negotiate detailed feature functionality.

Constantly reevaluate the product backlog in light of what we are learning from the emerging solution. Don't assume that the original features are the right features to deliver the vision. Stay open to new information and be willing to learn. If you find that what you are learning is moving you away from the original product vision, ask the hard questions about the project and help the business decide if this new direction is consistent with the organizations goals. If not, what does this mean for the product?

Dealing with business risk involves balancing the product vision, market needs, and the emerging solution. Maintaining the right balance between these three factors is how we guide the project into a successful outcome.

Next post... Technical Risk

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/05/agile-risk-mana.html

Subscribe to this blog