Inverting the Iron Triangle

I'm curious. Do we all agree that you cannot predetermine the time, cost, and scope of a project and have any hope of being successful? Is it not an axiom of project management that you can fix any two of the constraints but the third has to be variable? Up until recently I had always assumed this was the first law of project physics, the one rule that could not be broken. For some reason I thought that everyone understood this concept.

It is amazing to me how often I find myself talking to people about the triple constraints of project management. I am usually off talking to a group about Agile Project Management when someone raises their hand and asks THE QUESTION:

How does this work on my project where time, cost, and scope are all fixed?

The simple answer is this… it doesn't. The reality is that no project management methodology works when you try to lock all three of the constraints. If this is really true, why is it that Project Managers are constantly asked to manage projects with all three constraints determined in advance? As project managers, why are we so willing to go along when we know we're on a path to failure.

I want everyone to know that I totally understand the desire to have it all figured out up front. It is incredibly appealing to think that we can do enough due diligence and planning such that all three constraints become perfectly clear and manageable. The reality is that it just doesn't work that way. Claiming that this is our reality does not make it so.

Project Managers are in a tough spot. When you have a team of execs that are convinced we can plan our way into certainty, it is very difficult to be the person that raises the flag. Being the guy that draws attention to the elephant in the room is not a formula for career advancement. Put your head down, do the best you can, and hope for the best. Maybe we'll get lucky.

The data is showing us that more often than not... we don't get lucky.

If we are willing to accept the reality of the triple constraints, maybe we can begin to have a reasonable discussion about the kinds of decisions we are making about our projects. Let's talk honestly about what is really flexible and what is not. If we have no room to adjust the plan, what does that mean about the risk to our initiative?

When considering Agile methods, there is a fundamental shift in what we are choosing to assume about our project constraints.

Traditional project management usually starts with a discussion of scope, as in "what's the scope of the project?" From there we estimate the amount of work required to deliver the scope, set the project budget and resources, and determine the timeline. If your lucky, you get some room to negotiate on the front side. More often than not, the discussion ends with someone telling you to get it all done by next Tuesday. Even with room to negotiate, the goal is to lock the constraints and get moving.

Agile Project Management starts with a discussion of time to market and cost, as in "when do we need to get a working product to market and how much are we willing to invest." From there we begin the process of estimating how much scope we think can fit into the window. That estimate is not a fixed commitment. We started with the assumption we wanted to fix time and cost. Scope has to be negotiable.

There are implications to taking this approach. We'll need to look at how we structure contracts, how we forecast revenue, and how we make commitments to our customers. When we plan our portfolios, we have to ask if we can realize sufficient ROI - understanding we might not get every feature we originally hoped for. This is what is means to REALLY manage our projects.

Dealing with reality is not always easy. Agile is not a silver bullet. Pretending is not an answer.

For an interesting metaphor about dealing with uncertainty, take a look at Brian Sondergaard's post on Progressive Refinement of Estimates:
http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html

Link to my post on Agile Chronicles:

http://blog.versionone.net/blog/2008/04/what-about-me.html

Subscribe to this blog

Subscribe to Leading Agile

Assumptions are Made to be Validated

"Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to a project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions." - A Guide to the Project Management Body of Knowledge, Third Edition

Making assumptions is essential in project management. Assumptions simplify our understanding of the problem domain and allow us to move forward in the face of uncertainty. Without the ability to make assumptions, our projects would become paralyzed, unable to deliver the value for which they were created.

The success of our projects is largely determined by the quality of our assumptions. Therefore, by making assumptions on our projects, we are accepting some degree of risk that our assumptions could be wrong. Anytime we assume risk, we need to understand the probability the risk will be realized and it's potential cost to our project. In other words, it is not enough to make assumptions, we need to understand the risks associated with those assumptions, and have a plan should they prove invalid.

Systematic and thorough validation of our project assumptions is the foundation of good project management.

Traditional project management (by that I mean project management as prescribed by the PMI, documented in the PMBOK, and certified through the PMP) makes one key assumption that no one seems to want to address. We routinely assume that our projects are predictable. We assume that with enough planning, with enough forethought, that we can come up with a strategy that will hold through the life of the project.

While I am certain there are some project domains where this assumption holds true, I am equally certain there are many domains where it does not. As project managers, we owe it to our stakeholders to thoroughly assess the likelihood that this assumption is valid and have a mitigation strategy in place if it is not.

If we operate in an environment where market needs change, requirements change, technologies change, and individual performance can vary exponentially; spending effort trying to create a static project plan is wishful thinking. It is just not good project management. We need a mitigation strategy, we need an alternate approach to deliver our projects in the face of overwhelming uncertainty.

Agile methods give us a way of handling projects when the assumptions about predictability just don’t hold. Agile methods give us a way of delivering the most project value, in the least amount of time, with the least investment possible. Agile methods represent a risk mitigation strategy for when our fundamental assumptions about project management no longer prove valid.

Let's apply good project management technique, validate our assumptions, and work to mitigate our risks. Don't be afraid to challenge the assumptions behind our understanding of PM best practice. The assumptions you fail to consider are the most likely to cause you problems in the end.

Click here for my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/assumptions-are.html

Subscribe to this blog

Subscribe to Leading Agile

One Team

Why is teamwork such an important part of the agile value system?

As people work together over time they learn each other's abilities and communication styles. They learn how to interact with each other in ways that are more productive. Teams develop a culture and establish norms that allow for very efficient communication. They learn to leverage each other's strengths. Over time, this allows a team to establish predictable throughput and a regular pattern of delivery.

We often underestimate what it takes to bring people into relationship with each other. We seem to think that we can matrix people into teams and expect them to start performing right away. We seem to discount the fact that teams need time to form and get to know each other before they can be productive. We overlook personality and chemistry between team members and expect everyone to operate as if they've worked together for years.

The belief that we can breakdown and reform teams on the fly is a belief in local optimization. It is a belief that if we optimize the abilities of the individual through specialization and optimize the process through definition of best practice, people become interchangeable. Aside from the interpersonal issues we've just discussed, this has led our industry toward an ever increasing level of resource management, project management, and portfolio management complexity.

Our challenge is that we focus too much of our limited time and energy managing complex resource interdependencies rather than solving our real business problems. Simplifying means we focus less on developing individual specialties and more on the overall capability of the team. To optimize our teams we will have to broaden the teams collective skill. We have to let go of our addiction to individuals with specialized knowledge that become a single points of failure. We need more people that know more things.

This will require courage and a commitment to broadening the skills of our people. It will require a commitment to team building. It will require commitment to the belief that a well functioning team can deliver more than a collection of talented individuals.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/one-team.html

 Subscribe to this blog

Subscribe to Leading Agile

Herding Project Managers

Last week Glen Alleman published a post called "The Role of Project Management". Glen has been exploring some of the concerns people have with the PMI and the PMP certification. He is challenging us to tell him what process groups and knowledge areas we should leave out. What should we NOT be doing that the PMI prescribes? If we think that the PMI has it wrong, what should we be doing differently?

It dawned on me after reading his post that most Agile Practitioners I talk with don't really have much first hand knowledge of the PMI, the PMP, or the PMBOK. They know of these things through the people that they have worked with over the years. Quite a few folks I meet have had pretty bad experiences with PMP certified project managers and therefore think that it must be the PMI or the PMP that is making them bad.

For the sake of helping everyone rise to Glen's challenge, I have attached the PMI Process Groups, the Knowledge Areas, and as an added bonus, the Project Management Processes. My guess is that the Process Groups and Knowledge Areas are going to make the cut. What about the PM processes? Any low hanging fruit? Activity sequencing maybe? What about activity resource estimating? How about managing the team?

This is looking to be a pretty tough assignment.

PMI Process Groups
(these are the high level components of the process)
Initiating
Planning
Executing
Monitoring and Controlling
Closing

PMI Knowledge Areas
(these are the areas we are managing within the process groups)
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurement

PMI Project Management Processes
(these are the actual process prescribed in the PMBOK)
Develop project charter
Develop preliminary project scope statement
Develop project management plan
Scope planning
Scope definition
Create WBS
Activity definition
Activity sequencing
Activity resource estimating
Activity duration estimating
Schedule development
Cost estimating
Cost budgeting
Quality planning
Human resource planning
Communications planning
Risk management planning
Risk identification
Qualitative risk analysis
Quantitative risk analysis
Risk response planning
Plan purchases and acquisitions
Plan contracting
Direct and manage project execution
Perform quality assurance
Acquire project team
Develop project team
Information distribution
Request seller responses
Select sellers
Monitor and control project work
Integrated change control
Scope verification
Scope control
Schedule control
Cost control
Perform quality control
Manage project team
Performance reporting
Manage stakeholders
Risk monitoring and control
Contract administration
Close project
Contract closure

Check out this link just for fun: http://www.ibiblio.org/Dave/Dr-Fun/df200210/df20021001.jpg

 Subscribe to this blog

Subscribe to Leading Agile

We're Agile, Now What?

You’re a PM working with a team that has just gone agile. Here are a few tips to help you be successful managing agile projects:

Understand agile team dynamics

Agile is about creating an environment where team members are fully engaged and empowered to make decisions. A good agile team is transparent and apolitical. It is a fun and safe place to work. A big part of your job as an agile project manager is to create this environment for your project team. The more you can understand about what makes agile teams work, the better positioned you will be to help them be successful.

Champion the project vision

Sometimes the team is going to get in the weeds. Your job is to help them stay focused on the big picture. Own the project vision. Keep it front and center during planning meetings. Use the vision to make sure the team stays on course. Keeping everyone focused on the goals of the organization is a huge contribution to your team and the business.

Remove obstacles

Listen to your team. Understand what they are telling you. Become an enabler by helping the team deal with the problems that are slowing them down. Be proactive and help anticipate risks. Deal with issues before they become impediments. Create a network of informed company leaders that can help resolve issues when they get too big for the team to deal with locally.

Focus on team building

Create opportunities for the team to have a shared experience. Create an environment where people can develop strong relationships at work. Help develop a sense of shared purpose and camaraderie. Great teams work together and like each other. Great teams are sensitive to each other’s needs. Don't let this happen by accident, be intentional about it.

Build consensus through facilitation

You have created a high performance team focused on the business vision. Get out of the way an let them deliver. At this point you become a facilitator for the team. Learn techniques that help people come to consensus and resolve conflict in a healthy way. Recognize ways to help ensure everyone on the team is able to contribute. Help the team find common ground and get moving.

Develop talent through coaching

Become a teacher. Help set expectations for the team. Most importantly, put people in position to be successful and give them the tools to deliver. One of the best ways to do this is to develop your coaching skills. Learn positive ways to give feedback. Create non confrontational ways to guide and instruct. Build relationships and be open to feedback in return.

Encourage structure and discipline

Maintaining structure and discipline requires energy. One of your primary responsibilities is to help the team maintain focus and protect the process. Encourage participation in planning meetings, daily stand-ups, and retrospectives. Help your product owners find time to maintain the backlog. Encourage discipline around agile engineering practices. Help the team understand how all the practices work together.

Help the team commit

Agile is about delivering on time… every time. On time delivery requires commitment. It requires the commitment of the team to deliver the sprint and the commitment of the product owners to adjust as we learn more about the evolving solution. As an agile project manager you can help create a sense of shared ownership and a culture of collaboration and cooperation amongst all the team members.

Get help when you need it

Having a good support system is essential . Find people on the same road to share the journey with you. Seek out people that have travelled the road before you. Join user groups and share your ideas. Join organizations and find ways to contribute. You will learn much along the way. Never hesitate to ask for advice.

Be patient and stay the course

You are going to have challenges and you are going to make mistakes. There is a learning curve and some old habits will die hard. Hold yourself accountable and learn from your mistakes. Most importantly, don't give up.

Being an agile project manager is about being a great leader. It is about accepting input from reality and responding to it. It is about looking out for the best interest of the team. Seeking out what is not being said. Helping to bridge gaps in understanding. Exposing what is hidden.

There is no success for anyone unless we are all successful. By working for the success of the team, you are working for your own success. You cannot have one without the other.

Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/03/were-agile-now.html

 Subscribe to this blog

Subscribe to Leading Agile

The Agile Power Shift

Agile methods move us away from traditional command and control project structures and toward processes that encourage team empowerment and self-organization. This team centric approach represents a real power shift that can leave the traditional project manager wondering about their new role on an agile project.

Some have gone so far as to question if a project manager even has a role on an agile team.

In my last few posts I have been discussing the idea of simplicity and simple rules frameworks. I am trying to drive home the point that agile methods are not designed to tell the whole story. They are minimally prescriptive. They give us a handful of techniques and a whole lot of principles and values. These techniques, principles, and values serve as guides to shape our more complex decision making.

Our decisions must be guided by experience, and for many of us, our experience comes from many years managing more traditional projects. It comes from what we've learned on the job and studied in the PMBOK. A traditional project manager has the potential to contribute a wealth of knowledge, experience, and discipline to an agile project; there are a just few things we need to think about a little differently.

Being agile means you accept input from reality and respond to it. That is really the main difference. Let's embrace PMI concepts like rolling wave planning and progressive elaboration and really learn how to apply them. Let's figure out how to leverage what we know about traditional project management, get really good at accepting input from reality, and help develop project teams that are able to respond to changing circumstances.

Real power comes from helping the team be successful. Real power comes from delivering value to our customers. That is what Agile Project Management is all about.

 Subscribe to this blog

Subscribe to Leading Agile

Restrooms, Canoes, and Agile Metaphors

I came back to my desk yesterday and it was gone. Yep... just empty floorspace where my desk used to be. As you might imagine, VersionOne has a pretty mobile floorplan. Wireless internet and lots of power everywhere. The environment is pretty conducive to moving furniture around so people that need to work together can easily relocate.

After finding my desk missing, I went looking for it. I walked around upstairs, no desk. I walked around downstairs, no desk. I looked outside and then started exploring conference rooms... no desk. Hmmmmmmm. Where might my desk have gone? Well, it seems the dev team decided to play a little trick on me. They moved my desk into the ladies restroom. Nice.

To add insult to injury, they took pictures and posted them to the company blog. Check out http://www.agilechronicles.com/ for pictures and commentary. I have to admit that it was pretty funny having full power and internet access, all my books and even my lamp all crammed into a bathroom. Imagine the productivity gains not having to step away when nature calls. The possibilities could be endless.

It was a nice reminder that work does not have to be serious all the time and you have to be able to laugh at yourself. Now I have to figure out how to get 'em back! Paybacks can be hell.

On another not-so-serious note... I got a canoe a few weeks back. I really like my canoe. Even better, I like that I got a really, really good deal on a used one I found from a seller nearby my house. I had the opportunity to take my kids out a couple of times last weekend and we managed not to flip it over in the lake. We have some family coming up from Florida this weekend and I think we'll take it out again. Hopefully we'll have similar luck.

Activities like canoeing are great agile metaphors. It is all about heading out in a particular direction, course correcting along the way, paying attention to your environment, and adapting as you go. You have to communicate with your partner to get the canoe going in the right direction and to establish a stable velocity. You need to collectively maintain balance so you don't tip over. Sounds like a good blog for another day.

Life is good! Thanks for listening :-)

 Subscribe to this blog

Subscribe to Leading Agile

The Agile Elevator Speech

Okay… so you find yourself in the elevator with your CEO. She asks about the agile project your team is piloting. She wants to know what this agile stuff is all about. You have 30 seconds... go!

You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.

You go on to say that success in today's economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.

Your CEO is intrigued and invites you to walk to her next meeting. She wants to know more. Mission accomplished.

 Subscribe to this blog

Subscribe to Leading Agile

Scrum Project Management as a Simple Rules Framework

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves" - Ken Schwaber and Mike Beedle, Agile Software Development with Scrum

The Scrum methodology is elegant in its simplicity. It teaches us that when processes are not stable, and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. We must rely on observation. We must adjust the processes as we go and guide them to create our desired outcomes. Using this philosophy as its basis, Scrum is founded on three simple principles: make everything visible, frequently inspect outcomes, and adjust the process as necessary.

People really like simple messages and Scrum delivers in spades. Scrum is easy to communicate and the practices are rather straightforward and easy to implement. You can put a single diagram on a single page and talk someone through pretty much everything you need to know. There is power in the simplicity of the message and that has been a major factor in Scrum's rise as the de facto agile methodology in use today.

The simplicity of Scrum can be deceiving. That simple, straightforward message comes at a cost. Scrum is not all there is to software development and it's not all there is to good project management. If we are fortunate enough to have a group of really great developers, a fully engaged product owner, and a team that can operate with some degree of independence from the rest of the organization; the simple messages of Scrum are a great way to lead a project. The quality of the team allows you to get away with a barely sufficient methodology.

What about when our context is not so simple? What about when we have to develop complex systems architectures or work with a tightly coupled legacy system? What about when we have multiple teams distributed across the globe? What about when our product is an integration of several different products, each with their own product owner? What about when we have to deal with procurement or complex human resource concerns?

Scrum is silent on these issues.

Scrum abstracts these answers behind the team's ability to "devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves". While we are beginning to answer some of these questions, Scrum doesn't really give us much guidance on how to pull it all together. There is clearly more to the story than Scrum is prepared to address.

You know what though? That's okay.

It's okay because Scrum is broad enough to provide simple rules for one set of problems and a framework to handle more complex issues (and incorporate more complex strategies) as our teams need them. The simple rules of visibility, inspection, and adaptation don't break down. They have no geographic boundaries. They don't care about the size of your team or the expertise of your team members. They are about how we are going to control our projects in the face of uncertainty.

Scrum is a barely sufficient, simple rules framework for developing great products. It gives us space to apply our knowledge and skills and the freedom to adapt to our surroundings. We just need to be aware of what Scrum leaves out and be prepared to fill in the blanks. That said, I would rather be given a framework for adaptation than a heavyweight methodology. Very seldom in software is there one best way to do everything. Our processes should not assume otherwise.

 Subscribe to this blog

Subscribe to Leading Agile

Strategy as Simple Rules

"Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. " - Dee Hock, Founder and Former CEO of VISA International

My wife and I help run a small private school in our spare time. That pretty much means that we don't have much spare time left for anything else. Creating this school has been a great learning experience and can be very rewarding. It can also be very difficult at times balancing the competing needs of all our school families. It has taught us many lessons about what you can accomplish if you put your mind to something, are willing to work hard, and are willing to adapt.

When we started this school, the founding members decided that we value small class sizes and affordable tuition. This philosophy has proven to be a key differentiator for our school and has allowed us to more than double in size over the past year and a half. That said, a business strategy that calls for fewer customers and less revenue can be a little risky. As you might imagine, we have to run a pretty tight ship to keep our little school afloat.

Regardless of the challenges we have faced over the past several years, we have always come back to the idea that we must have small class sizes and affordable tuition. When we are tempted to add more students and ease the financial pressure, we think back to why we founded this school and what makes is special. When considering a tuition increase to provide more services, we think about our promise to keep tuition affordable.

These simple rules have formed the basis of what has become a pretty complex strategy. The rules give guidance to the kinds of teachers we can hire, how we moderate our service offerings, our organizational structure, and our recruiting. The rules form the basis for both our short term and long term growth plans and ultimately shape our vision for the future.

In short, the rules provide a framework to guide our more complex day-to-day decision making.

Even though our school is a non-profit, some days looking more like a ministry than a business, we exhibit all the characteristics of a small startup. We are learning our market, we are learning our customers, we are learning our employees, and as leadership, we are learning each other. It is impossible to predict everything that we will encounter along the way, so by necessity, we have to be open to change… willing to adapt.

Our growth this year has been very challenging. It has stretched some of us to our limits with regard to what we are willing to personally sacrifice to make this school work. People are unpredictable and our school is full of them. It is very tempting to want to put rules in place to manage that unpredictability. We have struggled to stay focused on keeping things simple, to engage people in a way that is empowering and affirming and makes them want to be a part of our school.

We are learning, we are trying to adapt, and to that end, we are extending our simple rules strategy.

Right now we are working to identify our key roles and our key processes. We are looking for a few simple rules to guide how each one operates. Just like we have a few simple rules that influence how we manage our business, we are looking to identify a few simple rules to give direction to our staff and volunteers as they manage their day to day activities. The idea is that as we grow, we want to empower more people to be in charge of more parts of our school.

As leaders, we create opportunity and provide direction. The simple rules will give our team guidance on how to operate in alignment with that direction. Just think what we can accomplish if we are able to tap into the power and creativity of our entire school family; to allow our teachers and volunteers to make decisions, to adapt to their immediate surroundings, all the while staying in alignment with the direction we have set before them.

I think that is pretty powerful stuff and I am excited about what we will certainly be able to accomplish.

More on our school at: http://www.hopespringscs.org

 Subscribe to this blog

Subscribe to Leading Agile