Replacing the Iron Triangle of Project Management?

Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new 'agile triangle' that is based not on time, cost, and scope... but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat's post this morning, discussing ways to use Jim's agile triangle, it got me thinking.

The general idea behind the agile triangle is that we need to take the focus off of delivering to a set schedule, a fixed budget, and some predetermined set of deliverables; and focus more on the value the product is delivering. In principle I agree, but does it make sense to modify to triangle to deliver that message?

I've always looked at the iron triangle as a way to explain the relationship between time, cost, and scope. If you change one of the three variables, the physics of project management says that one of the others has to change too. If I want to add scope, time or cost has to go up as well. If I want to deliver in less time, I either need more budget or I need to reduce scope. If I want a less expensive product, I either need to reduce scope or reduce the time it takes to build it.

I'm curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn't give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.

We all know of projects that have come in on-time and on-budget, with everything the customer wanted, and have been total failures in terms of market performance. I agree that we need to focus on value and quality as first class citizens in the project management discussion. To me though, quality and value are attributes of scope, and it just comes down to the definition of done. Do we have features in our backlog that are 'done' when they have poor quality? Are they 'done' if the customer does not accept their value? Value and quality are part of the acceptance criteria of scope.

I would probably flip what Jim did a bit and leave time, cost, and scope as the vertices of the triangle, but just like Jim broke the constraints into three attributes, I would break scope into three attributes... requirements, quality, and value. So, the question is... are value and quality project constraints or attributes of scope. I think you know where I stand ;-)

Subscribe to Leading Agile

My Life is a Project?

When I'm giving talks or teaching a class, I often talk about how I think about nearly everything in my life as a project. So much so that my wife sometimes complains that she is not a project that I have to manage! She get's tired of talking about risk mitigation strategies and desired outcomes. She isn't particularly interested in understanding our assumptions or constraints and really does not like being called a primary stakeholder.

In all seriousness... I don't quite take it that far... but I do tend to see things through a 'project' lens.

Earlier this morning I came across a great post by Scott Berkund titled 'Everything is a Project'. I liked the post so much (for obvious reasons) that I sent it out as an 'Interesting Post...' over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:

@flowchainsensei Way too many things are projects - especially projects. Projects are dysfunctional, wasteful and anti-flow. Let's put an end!

And my response...

@ mcottmeyer I think that the project metaphor can be useful when we don't have level investment across product lines.

Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful... and where I think the concept is overused.

First... the simple definition of a project goes something like this... 'a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome'. I'm pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?

My personal opinion is that we often take the project metaphor too far and call too many things projects. Calling things a project isn't so bad unless it drives us to put too much project management overhead around the work or leads to dysfunctional organizational behavior. If you and I are working to get a few bugs fixed for the upcoming release... is that a project? If we can do the work in the same amount of time it would take me to assign a project manager, write a charter, create a project management plan, and develop even a simple WBS and schedule... I probably don't need to treat it like a project.

Here is another example where I think projects are misused. If I am a small company that is developing a single product, and my primary mission in life is to keep that product updated with new features and defect free... is the work I am doing project work? I may be inclined to have a "UI redesign project" or a "Revise the login and authentication project". Are either of these projects? They could be, but because of the nature of my environment, what we are really doing is ongoing product development.

These kinds of work would probably be better considered product development or operations.

But... what if I am building a custom solution that will be handed over to the customer at the end of the contract period. I may provide ongoing support, I may not. In that kind of environment, it might make sense to have a project manager and a charter... a formal risk mitigation plan and at least a high level schedule... even in an agile environment. I have touch points with my primary stakeholders (no, not my wife) and they have certain expectations about how their money is going to be spent. This sounds like it could be a good place to have a project.

Let's consider another example... What if my product company grows up and now we are supporting 20 different products and have 40 to 50 teams. Your product sets are not all the same level of maturity. Some are established and don't need incremental investment.. some are less mature and require new features to be added to meet market demand. The point here is that the investment in each product is not level and the business is making strategic decisions about where it will spend its money to get the greatest return. I think that projects make sense here too. We are making an increment of investment, over a pre-defined period of time, to get some desirable outcome.

So... do I think that projects are overused? Yes. Am I willing to say that all projects are bad and that the entire metaphor is outdated and always inappropriate? No. Like most everything we talk about here... you have to understand your context and not apply concepts blindly where they don't make sense. If your work is more operational and ongoing... that is not the sweet spot for project management. If your work is well defined and discrete, and it lends itself to the problem that project management is designed to address... I think the concept is valuable.

It is not a one size fits all world. I look forward to the conversation.

Subscribe to Leading Agile

Project Management 2.0

I put Project Management 2.0 as the title just to give Glen Alleman a moment of pause ;-) Actually, Andrew Filev has posted 33 of his favorite thought-provoking blogs on Innovation, Project Management, and Web 2.0. Since Andrew was kind enough to include Leading Agile... and he is asking his readers to vote for their favorite... I thought I would include a link to his post here.

Leading Agile is in some pretty good company... so if you have a moment... head on over and take a look.

Subscribe to Leading Agile

Managing Expectations about Uncertainty

One of the biggest differences between the PMI crowd and the Agile crowd has to do with our expectations about uncertainty.

The PMI crowd generally believes that a Project Manager is supposed to manage uncertainty out of the project. The Agile crowd tends to believe that uncertainty and change is something that should be embraced. Rather than managing OUT uncertainty, the agilist chooses to manage FOR uncertainty.

This difference fundamentally influences how we go about the business of planning projects... the artifacts we create... and how we interact with and manage our teams. The reality is that both worldviews have a place depending upon your context and problem domain. It's up to us [as Project Managers] to recognize the nature of the projects we are working on and choose the strategy most likely yield a desireable outcome... for both our project stakeholders and our external customers.

We cannot check our brains at the door and blindly follow ANY methodology. It's up to us to assess our situation and choose an approach that is suitable for the task at hand.

Subscribe to Leading Agile

Why Project Managers Like Documentation

Reposted from Artem's Agile Software Development Blog

Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.

Fixed Constraints and Up Front Design

Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.

In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.

Project Managers Want to Succeed

Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don't want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.

So… what can a project manager do to ensure success? Focus on paperwork and process.

Paperwork and Process Defines Success

Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.

Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.

We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.

Changing Behavior Will Take Time

If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.

Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.

I understand it is difficult to run an uncertain business. We can't wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.

Holding Project Managers Accountable

Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.

Unless we want mountains of documentation no one will ever read, let's stop holding project managers accountable for plans that should never have been laid in the first place.

Subscribe to this blog

Photo Credit: www.polaricecapz.com/books_b.html Subscribe to Leading Agile

More Talking to Project Managers

Here is my last post for Artem's Agile Software Development... republished here for the benefit of my Leading Agile readers.

Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.

If you are interested in catching up with the conversation, go back and take a look at my post "How to Talk to Project Managers" at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man...

This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.

Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.

My talk generally followed the outline from "How to talk to Project Managers". People were taking notes and seemed engaged... but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.

I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.

We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.

What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.

Here is some thinking I've done on these topics over the past year:

http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html

Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.

Subscribe to this blog Subscribe to Leading Agile

The Agile Project Plan

When we think about a project plan, what do we typically think about? Most people I talk with think a project plan is the schedule…. they think about the Gantt chart… the dependencies... and the critical path. The project plan can contain the schedule, but it is bigger than that. A project plan is a project manager's strategy for how the project is going to be run. It is a tailoring of the project management framework and describes what processes are going to be applied to run the project.

Business Case and Charter

My approach to writing project management plans is certainly not unique, but I am also not sure it is 100% standard. A good project management plan should start off with the business case and charter. This is a statement of the value we expect from the project and your authorization to move the project forward. These documents set context for the product vision and development activities. They establishe the project constraints, known risks, and any assumptions the business is making that could have an impact.

The Product Vision

The vision should describe the customers of the product and the value they will derive from using it. It might address the market segments you are going after and any business constraints the project is operating under. There can be quite a bit of overlap between this document, the business case, and the charter depending on how your team uses these artifacts. I like to think of the vision as the place we really get specific about the product and what it needs to actually do.

You can think of the vision as describing the actors or personas that will use the system, the major product themes, and major epics that are going to be delivered to market. I might also consider delivering a high level release plan to communicate the overall project schedule.

A Note on Documentation

When talking to an agile audience, I always try to be careful to state that these documents do not have to be 100 page monsters. If you are working with a small team and with an embedded and empowered product owner, these documents can live on a whiteboard or a wiki. If you are running a large, and possibly distributed program, you may want to leverage a wiki or some other lightweight electronic communication tool. If you are working in a traditional document driven organization, you might have to create something in document form. Just keep it as lightweight as possible.

The PM Knowledge Areas

Now comes where we describe how we are going to deliver to the expectations of the business. We need to state how we are going to manage cost, time, and scope and explain how our project will manage risk. We need to let the business know our strategy for communicating progress and how will we will ensure quality. We need to communicate what we are going to do if we need to buy anything or hire anybody into the team. We need to get on the same page about how we are going to make staffing decisions and how we will handle any HR issues along the way. We need to communicate how we are going to make sure everything is working together to deliver value.

These are not questions only for traditional teams, agile teams have to answer them too. Often, we assume these things because agile processes have the answers built in. It is just part of the process. Sometimes we need to be willing to explicitly communicate how we are going to proceed in language that the business understands. A lightweight project plan can be just such a tool.

It's all about communication

Sure... the plan might change... we want to preserve the ability to inspect and adapt. That is why we keep the artifact as lightweight as possible. The act of writing this stuff down makes sure that we think it all through, that we don't take anything for granted, that everyone has a common understanding of how we are going to approach the project.

I have had great success in the past walking my PMO through each of the PMI knowledge areas and documenting how our agile techniques are going to manage time, cost, scope, risk, quality, procurement, human resources, communication, and integration management. The point of the exercise is not about the document, it is about getting everyone on the same page, it is about communication and understanding.

After all... that should always be the point of documentation… communication and understanding.

Subscribe to this blog Subscribe to Leading Agile

Scream Free Project Management

So here is another post I originally did for Artem's Agile Software Development blog. This is one of my attempts to blend a non-agile topic (parenting) with agile thinking and project management. Hope you enjoy it.

Scream Free Project Management

A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.

The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying "I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm".

How about with our teams? We desire a certain outcome on the project, we might not be getting it, so we start to get anxious. We might not scream at our team but we do exert pressure, we threaten, we manipulate, and we control. When we behave this way as managers, we are in effect screaming at the team to change their behavior so we can be at peace.

The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.

As project managers we need to get ourselves under control first. We need to operate from a position of confidence and strength. It is up to us to lay out the vision and lead the team. We can establish boundaries and set guidelines for behavior. As project managers we monitor the system, give support, and ensure accountability.

At the end of the day… an empowered, self-directed team will deliver more than one that is being heavily managed. It is this kind of team that will help us meet our goals and deliver on the objectives of the organization. Our anxiety is all that is standing in our way… it the only thing stopping us from creating the kinds of teams that are really going to deliver. The challenge is that we have to get ourselves under control first!

Projects come in all shapes and sizes. Some are software… some are community organizations… and some projects live in your house and eat all your food. Focus on creating context… focus on managing the environment… focus less on managing people and controlling outcomes and you've got a much better shot at making things happen.

You'll lead a richer life and have more fun along the way.

Here is a link to the original post on ASD: http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/scream-free-project-management

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Human Resource Management

Back so soon? I told you guys it was time to get this knocked out! Last post we talked about Quality Management, this post we are going to hit Human Resource Management.

According to PMI, Human Resource Management includes the processes that manage and organize the project team. Pretty simple huh? This is an interesting topic because we generally want agile teams to be self-managing and self-organizing. Do we throw this one out all together? Is there any way we'll be able to bridge the gap?

I've got to honest with you guys, I am not exactly sure where this one is going to end up. Let's jump in and see what we can do.

Human Resource Planning

PMI Definition: Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan

Does a RACI diagram have any place on an agile team?

Agile tends to assume that you are staffing your team with specializing generalists. What is a specializing generalist you ask? These are people that may have specialization in a given area but are willing and able to operate outside their area of specialization.

Specialization is problematic because it leads to matrixed organizations. If a specialized skill set is required only part of the time, we need to find something else for that person to do with their downtime. Organizations end up filling that downtime with other project work. The problem here is that working on more than one project dilutes focus and creates artificial dependencies between projects. Real dependencies are one thing, self imposed dependencies are quite another.

Specializing generalists allow me to have a single person do more than one kind of work, eliminating constraints, and reducing the need to matrix people across multiple projects.

Teams work best when they stay together and are all focused on a common objective. They establish a stable throughput, they trust each other, they understand how to work together. Agile values continuity and it's part of what keeps agile teams fast and lightweight. This is a very difficult, if not impossible, to achieve in a matrixed organization.

That said, we still need to know overall what skills are required. We need to do the necessary due diligence to make sure that our team collectively has the competencies required to deliver. We need people that can potentially fill several roles on the team. If a RACI diagram helps you figure that out… go for it.

Acquire the Project Team

PMI Definition: Obtaining the human resources needed to complete the project

After giving this one some thought, I don't think agile has much to say here or much overlap with PMI. I'll just take this opportunity to restate the importance of building teams with specializing generalists. Getting the right people on the bus makes all the difference.

Develop the Project Team

PMI Definition: Improving the competencies and interaction of team members to enhance project performance

Agile teams improve competency through collaboration and teamwork.

How does collaboration and teamwork come into play on agile teams? Most teams will have a mix of senior people and junior people, people who are better in one are of the application than in another area of the application. Agile encourages close collaboration amongst team members, pair programming, and shared ownership. It gives everyone the opportunity to broaden their skillsets, learn new technologies, and become proficient in areas of the application they might not otherwise touch.

Daily standup meetings keep people involved and connected with each other. Retrospectives help the team learn from each other and decide how to work together more effectively. Creating this collaborative learning environment is one of the reasons that collocation is such an important aspect of building agile teams. Agile leaders value team building and collaboration so much, they tend to focus more energy on activities that give opportunity to develop closer interpersonal relationships.

If your team members lack a particular competency, and no one on the team has that skill, training one or more folks becomes a critical success factor. Make sure you have that time and money in your overall project plan for formal training.

Manage the Project Team

PMI Definition: Tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance.

Ideally we want our teams to be self-managing and self-organizing. Give people the objective and get them the environment and the tools they need to deliver. The agile project manager can play a huge role in creating the kind of environment for this kind of behavior to emerge.

An agile PM needs to lay out the vision, make sure the team has the necessary skills to do the job, layout the initial planning structure, establish the metrics, and support the team by removing the things that get in their way. Part of establishing structure is keeping things visible and maintaining a culture of accountability. Iteration planning, daily stand-ups, product demos, and retrospectives help create this culture.

As an agile PM, I almost always track project burndown, iteration burndown, defect trends, and historical velocity. These metrics, in conjunction with the daily standup, usually give me a pretty good idea of how the team is doing. There have been times when I have needed to track individual hours and individual velocity but these cases should be the exception to the rule.

Agile definitely puts more emphasis on leading the team over managing the team. The reality is that sometimes your team is not healthy and mature or in a good place to manage themselves. A good manager, with a focus on servant leadership, can help create an environment where teams can thrive and people can learn what it means to take full ownership of project outcomes.

Now if we could just get PMI to stop calling our team members Human Resources!

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Quality Management

Okay… it has been a while since my last installment in this series. Aside from my general inability to stay focused on a single topic (what was I thinking committing to a nine part series) I got really swamped preparing for Agile 2008. I've got two talks coming up in November on this material, one of which has a presentation due in early September, so I guess it is time to get busy and get this series wrapped up.

Last time we covered Communications Management, in this post we'll discuss Quality Management.

As always, let's start with the PMI definition of Quality Management. According to PMI, Project Quality Management includes all the activities of the performing organization to determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. There are three processes included in this knowledge area: quality planning, perform quality assurance, and perform quality control.

If you've been following this series, you'll know that my general approach with the PMI is to take guidance from the PMBOK and figure out how to satisfy the intent of the process with a more agile practice or principle. Agile is all over quality planning, quality assurance, and quality control but we often use different language to describe how we satisfy these objectives and we often plan for these activities in a pretty different way.

Let's see what we can do to bridge the gap...

Quality Planning

PMI Definition: Identifying which quality standards are relevant to the project and determining how to satisfy them

Quality planning is really about the initial set of assumptions (we make as an agile team) about how we are going to manage quality on our projects. As it relates to developing software, quality planning has mostly been done for us… it is implicit… it is understood by virtue of the fact that we are using an agile methodology.

When we have discussions about doing test driven development, pair programming, or continuous integration; we are making decisions about how we are going to handle quality. The decision to make use of acceptance criteria is simply a decision on how we will know we have met the requirements of our stakeholders.

Are we going to do unit testing? How about manual regression? Will we need to test for performance, scalability, or security? How will we know we have met any applicable regulatory or audit requirements? I would venture to say that most agile teams are having these conversations. Even if your team is not writing this stuff down or getting sign-off, you are implicitly developing your quality plan.

It is up to the team to balance how much of this needs to be documented. Ask yourself to what degree will a document facilitate understanding or help with stakeholder communication? Consider how much documentation is required by your organization. Keep things simple, minimally prescriptive, and make provisions to adapt your plan as you learn more about the emerging solution.

Perform Quality Assurance

PMI Definition: Applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet the requirements

You've made some initial decisions about how your team will meet the quality expectations of the organization… now it is time to execute. Quality assurance is about making sure we are building the right product from the very beginning.

Early in the iteration, we meet as a team with our customers to define exactly what is to be built. Every role on the project has the opportunity and is encouraged to be involved. There are people looking at the requirements from every conceivable angle: system architecture, development, QA, analysis and design, and usability. We explore the problem from all perspectives, before we set off writing code, to ensure we are building a complete product.

Once we get started building out the features, we immediately execute our testing plans. At a minimum, agile teams are writing unit tests and doing continuous integration. We know at every moment of the project how well the code is performing against the requirements.

If your team has dedicated QA members, the QA folks are testing right along with the development team. Sometimes it is more exploratory and we are not looking for sign-off, we are really looking for feedback. Feedback from the QA team is essential to making sure that the product is evolving according to the quality standards we agreed to at the beginning of the iteration.

The team holds itself accountable by meeting in a daily standup. This allows the team to stay plugged in, assess progress, and identify impediments. In addition, the team has constant access to the product owners. This constant visibility allows the customer to fine tune the solution, as it is being built, to ensure that the product will meet market requirements.

Perform Quality Control

PMI Definition: Monitoring the specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

Even though quality is the focus from the very beginning in an agile project, we still seek to validate outcomes and formally track the quality of the product we are building.

The advantage of automated testing is that we know the health of the product in real time. We are able to measure and track defects and get them resolved as soon as they are introduced into the build. Manual testing, in parallel with the automated testing, gives a more intuitive way to exercise aspects of the code the are difficult to automate.

As a project manager I am constantly tracking burndown at the project level to see how well the team is doing against the backlog. Within the iteration, I am tracking task progress to make sure that we can deliver on our commitments. Agile teams also track defects, defect status, and test trends. All this gives the team a way to continuously control the project quality.

Agile teams don't wait until the end of the project to test, when we have the least amount of time to actually fix a problem, or respond to a change. We know at all times the health of the project, if the team is burning hot, if defects counts are trending up or down, how well we are resolving issues, and if those issues are becoming impediments to getting new product built.

Agile teams review features with their customer as they are completed. They do formal product demonstrations and retrospectives at the end of every iteration. These processes allow the team to control, not only the quality of the emerging product, but also of the processes we are using to deliver that product.

All of this feedback gets folded back into the plan, adjustments are made, and the team adapts based on what they have learned from regularly delivering code.

Next up… Procurement and Human Resources. We'll save Risk Management and Integration Management for last!

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Communications Management

As promised… next up we're talking about Communications Management.

According to PMI, Project Communications Management employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. This knowledge area provides the critical links between people and information that are necessary for successful project communications.

There is a neat little book by Andy Crowe called "Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not". This book surveyed over 5000 project managers to find out what the best project managers are doing differently. One of Andy's conclusions is that top project managers spend significantly more time communicating than their less successful brethren.

In some cases these top project managers spent up to 90% of their time communicating in one form or another. I have to say, that is certainly consistent with my personal experience. If something is going wrong on one of my projects, it is usually because people are not talking to each other.

But maybe I am taking a naïve view of what it means to communicate on a project? It seems to me that the PMI definition of Communications Management is a little broader than just making sure the team is talking to each other. Communications management deals with documents and plans and stakeholders. Communications management is really about managing the flow of information.

Since it's common knowledge that Agile teams don't do documents, I am guessing we have some work ahead of us to reconciling these points of view.

Okay… I was kidding with the Agile documentation comment. That said, there is clearly a difference in how these two project management perspectives treat the issue of documentation, reporting, and even interpersonal communication.

Both PMI and Agile have quite a bit to say about how to manage project communications so let's get started.

Communications Planning

PMI Definition: Determining the information and communication needs of the projects stakeholders

When Agile teams talk about communications, they are usually talking about communications within the team. Agile puts a great deal of emphasis on the free flow of information between team members, between team members and the product owner, and even between the team and the direct customer. In some ways, the Agile community has really abstracted the entire stakeholder community behind the role of Product Owner.

Communication between team members, and between the team and its customers, is essential but it is not the only component of communication that must be planned. Sometimes there are other stakeholders that we must take into consideration.

At the team level, we usually deal with team member communication through collocation, whiteboards, wikis, and other rich and collaborative workspaces. Agile teams trade a great deal of written documentation for these more osmotic forms of information exchange. On a small team with a single customer, it might be sufficient to suggest that customers get all the information they need from attending planning meetings, daily stand-ups, and iteration reviews.

When there is more than one stakeholder, or possibly a hierarchy of stakeholders , sometimes it is not sufficient to suggest that these stakeholders come down to the team room and check out the team's progress on the Kanban board. Sometimes we need to do some roll-up reporting across a portfolio of projects or even programs. Sometimes we need to report status at a much higher level of abstraction for a more senior audience.

The key to planning communications on an Agile project is to follow the principle of simplicity. Don't write documentation for the sake of documentation. Find out what your stakeholders really need and provide it as quickly and as simply as possible. Make use of natural information sources that the team is already producing (task boards, burndown charts, architectural representations) and create documentation that enables your business to make decisions.

Keep things light, go for face to face whenever possible, and when your stakeholders require more; make things as simple, clear, and accurate as possible.

Information Distribution

PMI Definition: Making needed information available to project stakeholders in a timely manner

At the team level, information distribution focuses on those rich channels of communication I mentioned in the last section. Agile teams keep their status up to date using large, visible information radiators that everyone in the team room has access to and can update themselves. These repositories of information are there for the team to know where it is at all times and so they can manage their work. The side effect of these radiators for the Project Manager is that you have instant access to real time information about the health of the project, release, or iteration.

Often, design and architecture will be worked out on whiteboards and then minimally documented on a Wiki or Sharepoint so they can be easily changed as we learn more about the evolving system. Agile teams lean toward lightweight artifacts and central, universally accessible document repositories. Agile teams recognize that the only truly accurate representation of the product is the code itself ; therefore documentation is kept light and at a pretty high level.

Sometimes a customer has a need for more detailed documentation to manage an external dependency or possibly an audit requirement. In these cases, that increased level of documentation is built into the estimate for the feature. Documentation is not free and it will slow down the creation of working software.

The key once again is to figure out what is the minimum amount of documentation needed to satisfy the requirement. Document systems at the highest level of abstraction you can get away with. Make sure you understand the information needs of the external stakeholder, make sure that work is represented in the backlog, and that it is prioritized to meet the needs of the organization.

Use the same collaborative techniques you would use to build features to create the documentation required by the business.

Performance Reporting

PMI Definition: Collecting and distributing performance information. This includes status reporting, progress measurement, and forecasting

Okay… so we've already talked about things like burndown charts and Kanban boards. These are tools that a team will use to organically manage their work and make sure they are on track. As an Agile project manager is your responsibility to help the team and encourage that these tools are kept up to date. For the most part, these are the only tools you will need to understand the health of your project, and you largely get them for free.

Performance on Agile projects is pretty simple. You know how big your backlog is and you know how much you are able to complete each iteration. Based on these two variables you are able to predict how many features you will be able to complete before the end of the project, release, or iteration. I personally like to keep a high level project roadmap that helps me understand where the project is expected to be at certain points as it progresses to completion. This is also useful for managing external dependencies.

These simple tools help you understand what progress you are making against expectations and if you'll need to extend the release, adjust scope, or request additional funding. Since you are an agile team, you'll more than likely be communicating how early you'll be, how much more you'll be able to do, and how much more value you've delivered to the organization.

Either way, you have a tremendous amount of information at your disposal to communicate project to the project stakeholders. Think EVM based on delivery of working product.

Manage Stakeholders

PMI Definition: Managing communications to satisfy the requirements and resolve issues with project stakeholders.

Managing stakeholders is really about managing the issues that come up during the life of the project. A significant benefit of Agile is that nothing is hidden. This level of visibility gives the project manager the information they need to resolve problems and remove impediments.

Issues can arise during iteration planning, execution, closedown, or just in the course of day to day work. Just like on any project, these need to get tracked and dealt with as soon as possible. Issues are reviewed during the daily stand-up meetings and retrospectives.

There are always going to be some issues that cannot be dealt with by the team. I typically hold a weekly or bi-weekly meeting with senior stakeholders where they get a distillation of significant impediments and what I need them to do to help me resolve the issue.

It is my opinion that stakeholders need to be managed and issues resolved no matter what your software development methodology.

I think that does it for this installment. That was much longer than I had expected. I figured communications management would be one of the easier topics to discuss. Maybe I just need to go home for the day.

Let see… next up… Quality Management.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Scope Management

Okay… let's get back to our discussion on how to look at the PMI knowledge areas from a more Agile point of view. Last time we tackled Cost Management, this post let's look at Scope Management

According to the third edition of the Project Management Body of Knowledge, Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. PMI states that project scope management is primarily concerned with defining and controlling what is and is not included in the project.

I find it a little entertaining how these statements seem to be universally interpreted as "define everything you are going to do up front and make sure you deliver what was originally defined". While that may have been the intent of the PMBOK Guide, some projects don't lend themselves to that kind of up front planning. Some projects must allow for discovery. Some projects must adapt to changing markets, or at the very least, adapt based on the teams understanding of the emerging product.

For some of us working in more dynamic problem domains, ensuring that "the project includes all the work required", is a process of discovery. Controlling what is included, and what is not included, is an ongoing concern rather than something done once for the entire project. We need a project management framework that embraces this uncertainty rather than wishing it away or pretending it doesn't exist.

I am becoming convinced that Project Managers default to this static point of view because we have never been taught another way of managing projects. We just don't have the tools to deliver projects any other way. So… that said, let's take a moment to look at the PMI Scope Management processes from a more Agile point of view. I bet we find another way of approaching Scope Management that does not involve defining everything up front and then locking it down for the duration of the project.

Scope Planning

PMI Definition: Creating a project scope management plan that documents how the scope will be defined, verified, controlled, and how the Work Breakdown Structure will be created and defined

Agile project management practices are really the embodiment of a scope planning approach. As a project manager, especially a traditional project manager making the switch to Agile, I have no problem documenting this for my organization. An Agile Scope Management Plan is going to address things like creating the backlog, characteristics of a good backlog item, how we are going to establish velocity or throughput, how we are going to measure burndown against the backlog, and how we are going to deal with changes to the backlog.

Scope Definition

PMI Definition: Developing a detailed project scope statement as the basis for future project discussions

Scope on an Agile project is defined in the product backlog. The backlog is a listing of the features that your product owner would like to have included in their project. One of the most important considerations to keep in mind is that every item in the backlog should be independent of each other. This is the secret sauce that makes it possible to reprioritize and make changes on the fly. Bill Wake has a great explanation of what makes a good backlog item on his website: http://xp123.com/xplor/xp0308/index.shtml.

Rather than looking at the product backlog as a static indicator of what WILL be built, look at it as the baseline for further adaptation. It is expected to change as we learn more about the emerging product.

Create WBS

PMI Definition: Subdividing the major project deliverables and project work into smaller, more manageable components

This is one of the toughest things for traditional project managers to get their heads around. There is no WBS on an Agile project, at least not one in the traditional sense. From the Scope Definition section, we learned that our backlog represents the scope of the project and that each of the backlog items should be independent of each other. Independence is key because it allows us to do just in time scheduling.

Agile projects are broken down into smaller projects called releases. Project releases are broken down into smaller time-boxes called iterations. Content is pulled into a release just prior to its start, and only as the previous release is winding down. Likewise, content is only pulled into the upcoming iteration as the previous iteration is coming to a close. The idea here is that we are going to review what the team was able to complete and make decisions about the next increment based on what we learned from delivering the previous increment.

As an Agile Project Manager, I am generally comfortable laying out a high level plan to understand where I expect to be at certain points in the project. I am also comfortable keeping a chart of external and internal dependencies to help manage commitments. The key is to use these as guidance for decision making and indicators of progress. Problems arise when these tools restrict our ability to learn and adapt to the realities of our projects.

Scope Verification

PMI Definition: Formalizing acceptance of the completed project deliverables

Each iteration we will decide the next best increment to build and then review the outcome once we are complete. The stakeholders either accept or reject the outcome of the iteration and work with the team to decide the next best set of features to build.

Because we want to maintain the ability to adjust the product as we learn more about the emerging solution, we focus on making and meeting commitments in smaller increments. Scope verification is done based on the outcome of these small increments of product and how they align with the product vision and the goals of the release.

Scope Control

PMI Definition: Controlling changes to project scope

Agile teams take a value driven approach to delivery rather than an activity based, or even deliverables based, approach to delivering projects. The product owner can change the scope of the product at will, but is always focused on delivering the most value possible given the available times and resources.

Agile teams give the product owner a tremendous amount of discretion over how the system is constructed and even accommodate changes even late into the life of the project. It is understood by Agile teams that changing scope involves tradeoffs. The product owner is substituting features that add greater value for those that provide less. To add one thing, something often has to be taken away.

Next Up… Communications Management

Subscribe to this blog Subscribe to Leading Agile

Project Management is Not Enough

Are you a software project manager? If so, your job is changing. It is no longer enough to keep the risk list up to date. It is not enough being the person to schedule the meetings and do the minutes. Knowing how to calculate earned value and critical path is the price you pay to even call yourself a project manager.

Great project managers take those skills for granted. Great project managers are defined by how well they lead their teams. Great software project managers establish context. They create organizational alignment and guide their projects toward successful project outcomes. Great project managers focus on team building, they open lines of communication, they trust people, respect and empower them, and maintain sufficient control to hold everyone accountable for project outcomes.

In my experience, project managers tend to look at themselves in one of two ways. Some PMs want to be at the center of the project, in control of everything, in the middle of every decision. Like the illustration on the right, they try to be the center of the wheel with all team members connecting through them.

Others lead from the boundaries, they create the context. They establish the parameters of the project, the outer limits. They trust the project team to deliver the desired outcomes within those limits. These project managers build teams, get them what they need to be successful, and remove any barriers that could stand in their way. The project manager on the left is intentional about creating and maintaining connections between team members and acting as the buffer to the rest of the organization.

Traditional project management tends to focus more on the science of project management and less on the leadership and team aspects. Agile can sometimes focus too much on the softer side. It's my view that the process driven, scientific side of project management should be a given. That is your ticket in the door. Its time we start hiring great project leaders. It's up to us to get serious about becoming great leaders.

Otherwise, don’t call yourself a project manager.

Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/06/project-managem.html

Subscribe to this blog

Photo Credit: http://www.projectstrategy.com

Subscribe to Leading Agile

Refactor Your PMP: Cost Management

Next up is cost management. According to PMI, cost management includes the processes involved in planning, estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. This knowledge area only includes three process, but as you might expect, we are going to put a little different spin on them and see what we can do to make them more agile.

Cost Estimating

PMI Definition: Developing an approximation of the costs of the resources needed to complete the project activities

We discussed in the last post that agile projects typically start with time and cost as the primary constraints and float scope through the life of the project. While this is true, there should always be some sort of assessment at the beginning of the project to determine what value the customer might expect at what level of investment.

The product owner might approach the team with a high level backlog of features that need to make the next release. The team would then estimate the backlog and calculate how many iterations they expect the work to take. There would be a negotiation of scope, team composition, and release duration as everyone comes to consensus around what is possible.

The cost of the project is then established as the product of team size and project duration.

Cost Budgeting

PMI Definition: Aggregating the estimated costs of individual activities or work packages to establish a cost baseline

Agile teams assess the relative size of each item in the backlog. Some teams also put a numeric value on the expected ROI of each feature in the backlog. In aggregate, the size of the backlog determines how many features can be delivered and thus the overall value of the release. Because costs are assumed to be a constraint, cost budgeting on an agile team is much more a statement of how much value can be delivered, over the life the project, for the approved budget.

The budgeted amount of value for the project is represented in the release backlog.

Cost Control

PMI Definition: Influencing the factors that create cost variances and controlling changes to the project budget

With the cost of the project now established as a project constraint, agile project are not nearly as concerned with controlling the costs and variances of individual work items. Agile teams are most concerned with how quickly the project begins delivering value and at what rate. We need to monitor how well we are delivering the anticipated features and if we have deviated from the rate we had originally expected.

If the project is not progressing as well as we might have hoped, we may need to remove less important features from the backlog. This will decrease the value to the customer and implicitly increase the cost per feature. If the product owner chooses to extend the duration of the project, to realize all of the anticipated value, this would increase the real costs to the project.

Delivered value is tracked primarily by measuring project burndown. Here we assess the total value of the release, what value the team had expected to deliver at the end of every iteration, and compare the actual value delivered against the ideal.

By monitoring project burndown the team can assess and control the cost impact to the overall project.

Next up... Scope Management

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Time Management

The first knowledge area we are going to tackle is Time Management. According to PMI, time management involves those processes that contribute to the on-time completion of the project. This knowledge area includes six project management processes designed to accomplish this goal. We'll explore all six and see how we can adapt these processes to make them a little more Agile.

Activity Definition

PMI Definition: Identifying the specific schedule activities that need to be performed to produce the various project deliverables.

To make this process more agile, you first need to think in terms of defining the features of the system, not the activities. Up front we want to know how the system is going to behave. These feature specifications need to be small and independent of each other. Agile teams usually call these features a user story or a backlog item. Collectively the list of product features is called the product backlog. The backlog represents the scope of an agile project.

Activity Sequencing

PMI Definition: Identifying and documenting dependencies among schedule activities

While discussing activity definition, we stated that the backlog items need to be independent of each other. The reason they need to be independent is because we want to have the ability to change requirements as our understanding of the evolving system changes. By definition we are seeking to minimize the dependencies between the work items on our project. Sequencing on an agile project is based less on dependencies and more on risk and business value. We want to focus on sequencing based on which features are going to reduce the most risk and deliver the most value as early in the project as possible.

Activity Resource Estimating

PMI Definition: Estimating the type and quantities of resources required to perform each schedule activity.

In traditional project management approaches, we are usually trying to determine the type and quantities of resources when we know the least about what it is we are going to build. Spending time and money to get a better understanding of these variables is not going to yield a substantial return. Agile approaches use a technique of estimating that relies on the collective understanding of the team to determine a relative size estimate of the feature, often measured in units such as story points or ideal engineering hours. These units only asses the size of the feature relative to the other features in the backlog.

Activity Duration Estimating

PMI Definition: Estimating the number of work periods that will be needed to complete individual schedule activities

We've discussed that each feature in the backlog needs to be small. Our goal is to have every backlog item small enough that it can be delivered within a single iteration. Agile teams build in this constraint and then measure how many features they are able to complete in a given iteration. By measuring how many story points, or ideal hours, they are able to complete each iteration, the team can predict how many iterations it will take to complete the backlog.

Schedule Development

PMI Definition: Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule

Typical agile projects begin with a time constraint, iterations are fixed periods of time and release schedules are usually established at some fixed interval. Each of these are set by the team and the product owner, but once set do not change. That language might sound a little strong but agile is about building trust with your customer. Good agile teams can always make their date, it is the scope that will vary.

Schedule Control

PMI Definition: Controlling changes to the project schedule

Because the iteration and release timeframes are fixed, it all comes down to a discussion around scope. These discussions are a constant collaborative effort between the product owner and the team. The product owner always has the option of adding additional iterations to include more features. Because the features are discrete, and the team is always working on the highest priority features first, the product owner also has the option of calling the project complete at the end of any iteration.

As always, if you think there is anything I left out, or should have dealt with in more detail, please let me know via response to this post. I speak on this subject quite a bit so anything you have to contribute to make this brief explanation more understandable would be really appreciated.

Next up we'll deal with cost management processes.

Here is a link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/06/refactor-your-p.html

Subscribe to this blog Subscribe to Leading Agile

The Agile Edge Conference

Next week Valtech and VersionOne are co-sponsoring a one day conference called the Agile Edge. This will be an intense introduction to Agile designed to give attendees tools they can use to drive organizational transformation and breakthrough performance. David Anderson will be kicking off the event so it should prove to be a very informative and exciting day.

The conference will offer three tracks, each covering a different role on the project: product owners, developers, and project managers. I have the honor of doing the talks on the Agile Management track. We've prepared three presentations that are geared toward traditional project managers making the switch to agile.

Refactoring your PMPs
Successfully moving to Agile Project Management will hinge largely on how well we adopt new ways of thinking about project structure and control. Building on the principles of PMI and the Project Management Body of Knowledge (PMBOK) we will explore how a PMP can adapt their knowledge and experience to become an effective Agile Project Manager.

The Agile Power Shift
Agile methods build high-performing project cultures and put a great deal of emphasis on trust, empowerment, and self-organization. Agile moves us away from command and control project structures and toward structures that help us tap into the passion, creativity, and enthusiasm of the team. This team centric approach can leave the traditional project manager wondering about their new role on an agile project. This talk will explain the essentials of agile team dynamics, how teams contribute to project success, and what we must learn to become effective agile project leaders.

Agile Project Management Explained
Agile represents a dramatic shift in thinking about project management. It also represents a pretty radical shift in what a project manager does. At some point project managers have to transition from thinking about Agile to actually making it happen. This talk will explain the mechanics of running an Agile project and how these techniques support the principles behind Agile methodologies.

For those that cannot make the talk next week in DC, we'll be offering this conference in other cities around the country. Next up is New York on June 25th. Click here for more information and to register for the event. Looking forward to seeing everyone there!

Subscribe to this blog

Subscribe to Leading Agile

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

Subscribe to Leading Agile

Agile Risk Management - Technical Risk

This is part two of a mini-series on risk management. Part one discussed how I think about business risk. This post will address some things to think about when considering technical risk.

Technical Risk

Technical risk deals with those unproven assumptions in your emerging design that might significantly impact your ability to deliver the solution. Are we planning to use any unproven technologies to build the solution? Have we exercised the significant interfaces between systems? Can we demonstrate a working skeleton of the system? What about performance? What about security? Any technical decisions not validated by working software count as technical risks.

Technical risk deals with feasibility. In other words, have we proven there is a solution that can be delivered within the time and cost constraints of the project?

Technical risk is also dealt with early in the project immediately after you have a handle on the critical business risks. This is where the team really gets engaged for the first time. You bring your resources to bear to build out the system and validate any assumptions you made during planning. The backlog should be prioritized with an eye toward technical risk. Build out those features early that are most likely to validate your architectural assumptions and stabilize your emerging design.

It is worth emphasizing here that technical risk should always be mitigated in the context of working software. We build features to mitigate risk. Proving interfaces, or that one system can talk to another, outside the context of delivered business value does little to prove anything or mitigate any real risk. Testing is an integral part of risk mitigation. Untested features deliver no value.

As we build features, we will certainly learn more about the architecture and more about what it is going to take to build out the proposed solutions. Stay open to this new information. Re-estimate the backlog if necessary. Share this information with your product owner. Allow them the opportunity to learn along with you and adjust their plans and expectations accordingly. Look for technical tradeoffs that will allow you to deliver within the agreed upon time and cost.

What happens if you prove there is not a solution that can be delivered within the time and cost constraints of the project? Sounds we've just identified a pretty significant business risk. Mitigate your technical risks early and ensure feasibility while your overall investment is still relatively low.

Click here to read my previous post on Business Risk. Next post we'll address Logistical Risk

Subscribe to this blog Subscribe to Leading Agile

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

Subscribe to Leading Agile