Three Steps for More Effective Projects
Effectiveness > Efficiency
Has your IT organization ever been challenged to be "better, faster, cheaper"? If you're like most other organizations it may seem as if you are always in search of some way of improving your IT operations in order to get more done, to do it with higher quality, and to do all of that while spending less money. Certainly a tall order in most situations.
When most organizations are faced with this challenge, their first instinct is to improve their efficiency, which can help with the faster and cheaper if they can pull it off. Unfortunately, better often suffers as a result of faster and cheaper. After years of working with IT organizations facing this situation I've realized that they're facing problems partly of their own making.
My friend Jeffrey Davidson, having been on both the business and IT side of several projects, summed it up perfectly: "IT has spent 30 years teaching our business partners how to be bad customers. We need to fix this." IT organizations have taught business stakeholders to spell out everything they want (i.e., "tell us your requirements") and that IT will very rarely say no.
So how do we fix this? One huge step in the right direction is to start thinking more about effectiveness. I think of effectiveness as building the right things in the right way. Building things in the right way means approaching work with technical excellence. That's a topic for another article. What I want to focus on in this article is how to make sure we're building the right thing.
"There is nothing quite so useless as doing with great efficiency something that should not be done at all." - Peter Drucker
Organizations that focus solely on efficiency and utilization think that they can get more done, but they forget that when people try to do multiple things in parallel they often finish nothing. When people worry more about effectiveness -- working on the truly important things -- they improve the odds of getting things done and making a true impact on their organization.
Just saying no is not the answer. IT and business units need to build a partnership to determine what the right things are, and to know when those right things have been successfully delivered. There are three simple yet powerful steps you can take to determine the right things to build and, perhaps more importantly, what not to build. Those steps are: build shared understanding, provide guardrails for decision making, and measure based on outcome, not output.
Build Shared Understanding
Shared understanding answers two questions: Do we all understand the need we're trying to satisfy, and do we agree about the characteristics a solution should have? The people that should have that shared understanding are those who have the need (usually sponsors and stakeholders) and those who deliver the solution (delivery team).
The act of building a shared understanding in a collaborative fashion is more important than the resulting shared understanding itself. The conversations that occur in this process give the delivery team a clearer understanding of the problems that stakeholders face and identify risks and assumptions that are relevant to an effective solution.
A technique I've used to guide these conversations is the collaborative problem statement, which I first saw in The Software Requirements Memory Jogger by Ellen Gottesdiener. The problem statement takes this form:
|The problem of ...||What is the problem we're trying to solve?|
|Affects ...||Who are the people affected by the problem?|
|The impact of which is ...||What is the impact of the problem on those affected?|
|A successful solution would ...||What are the critical benefits or key capabilities that the solution -- however implemented -- must have to be successful?|
You can use this template to organize your thoughts around the problem you're trying to solve.
I gather the sponsor, key stakeholders, and the delivery team together and ask them to write their perspective of the problem statement on four sticky notes. Then I put up four different sheets of paper on the wall and label each one for the four parts of the problem statement.
I ask each person individually read out what their statement looks like and then post those sticky notes up on the individual sheets. As each person reads through their sticky notes, it quickly becomes apparent whether a shared understanding exists or not.
I did this exercise once with a team of eleven (sponsor, stakeholders, and delivery team) working on a commissions system project. They had been working on this project for about six months when I walked them through the exercise. We had eleven people and eleven different perspectives about the problem they were trying to solve, ranging from making the commission system easier to maintain, to completely overhauling the way that the organization paid their agents.
Once everyone has their sticky notes up, the group goes from one sheet to the next to agree on a problem statement. The resulting statement is helpful, but the really powerful aspect is the conversation that occurs while the team is working through coming to an agreement. Conversations around each part of the problem statement can help with aspects of the project moving forward.
|The problem of ...||Determine the one problem that is most important to solve now.|
|Affects ...||Use the discussion on this part to identify the key stakeholders who are most relevant to your project and who you'll want to talk to in more detail.|
|The impact of which is ...||Answer the question, is this problem actually worth solving?|
|A successful solution would ...||Identify characteristics of and constraints on a successful solution. This part of the statement might also identify some conditions that you want to have in place once the problem has been solved.|
Ideally you have this conversation when you're just getting started on a project (or whatever you're trying to do) so that you start off with a shared understanding. However, I've found that teams don't have this type of discussion to start off with and they have to work through it as they go.
Provide Guardrails for Decision Making
Once you have a shared understanding of what you're trying to accomplish, the next thing to do is provide guardrails for the decisions that team members make. While the leaders of an organization will make key decisions such as whether to pursue a project or not, the members of the team make many decisions on a day to day basis that impact the project. In order to make sure the team makes effective decisions, they need to keep those decisions in line with the shared understanding of the need the project is satisfying.
A technique that's useful for setting guardrails is decision filters: simple questions used to guide decision making. Decision filters provide a quick way to communicate guardrails for a project to everyone involved in making decisions. To put it in the words of Niel Nickolaisen, who originally created the concept: "Decision filters help teams do the smart stuff better and stop doing stupid stuff." The format of a decision filter basically is: Will this help us do X? If the answer to that is yes, you keep moving forward. If the answer is no, then either don't do the thing you were putting through the filter, or change it such that it will meet the filter.
I recently worked on the Agile Alliance website redesign. One of the reasons we redesigned the website is to encourage more people to interact with the Agile Alliance. To keep that aim front of mind, we created a decision filter: Will this encourage practitioners to engage with the Agile Alliance? Then whenever we had to decide whether we were going to add or change some functionality, we'd run that through the decision filter.
Measure Based on Outcome, Not Output
Once you have built a shared understanding and have used it to guide your decisions along the way, you want a way to know and communicate how you're doing. In order to do that, you need to be able to measure what you're doing based on outcome, not output. Outcome is basically the change that you're trying to introduce. Think of it as asking, have we satisfied the need? Outputs are the things you produce in order to satisfy that need, or the solution. We want to measure progress and success based on the outcome we're getting, not the output.
Most teams measure progress based on output rather than outcome, primarily because it's easier. It's a lot easier to count the number of story points we've delivered. It's a lot easier to look at velocity. One way you can measure based on outcome is to establish clear, measurable business objectives that you can use to gauge progress and success.
For the Agile Alliance website, one of the main objectives was to increase engagement with the Alliance. One of the ways we figured we could measure that was to look at the membership signups. As a result, one of the objectives we created was new and renewed individual memberships per month.
The one trick with objectives is that you need to make a change and roll it out to actually see the impact of your work on the objective. There can often be a lag time in understanding the impact of your work. To account for that, pick metrics that you can measure frequently, so the lag between action and measurement is as short as possible.
How Can You Be More Effective?
I use three steps to increase my effectiveness and satisfy my stakeholders' needs better, faster, and cheaper. I ask:
- Does your team understand what you're trying to accomplish?
- Does your team have some means of making decisions about those things?
- Do you have strong ways of measuring your progress and your success based on those particular outcomes?
Have you tried techniques like these to become more effective? Have you tried other techniques? If so, please share them in the comments.