Managing Beyond Projects - #NoProjects

Allan Kelly, http://www.allankelly.net, @allankellynet

"Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist." John Maynard Keynes

Keynes was talking long before there was a software industry but his words still ring true. Too many practical men (and women) are today slaves to the project model of software development. The inadequacies of the project model condemn development initiatives, programmers and companies to failure.

If you've been following the #NoEstimates hashtag you'll have noticed that #NoEstimates has a suspicious sibling which raises its head from time to time, #NoProjects. For better or worse I have probably become the individual most closely associated with #NoProjects, although I hasten to add that I share parenthood with Steve Smith (@agilestevesmith) and Joshua Arnold (@joshuajames).

While the inadequacy of "projects" for software development, and especially agile software development, has been apparent for some time, the model is now hindering improvement. Advances brought on by Agile development, such as continuous delivery, have now reached the point where the project model is itself an impediment to the development of software.

Steve, Josh and myself independently came to the same conclusion about the same time. Although interestingly the three of us critiqued the projected model from different position: failure to maximise value, failure to minimise risk and failure to adequately portray the software lifecycle. Over the last couple of years these strands have entangled and I can no longer tell which of us was responsible for which bit!

In this article I'd like to run through the failings of the project model and sketch an alternative.

Show me the money

Consider the well-known success troika for projects:

• On schedule delivery
• On budget delivery
• On quality delivery

Think about this list of criteria, can you see identify a problem with these criteria?

This particular troika dominates project thinking. But something is missing.

Look closely. Can you see it?

Value.

These "success" criteria do not consider the value of the solution.

Value is usually taken to mean dollars, euros, sterling, a hard number. However it is better to consider value more generally as "business benefit" i.e. the benefit delivered to the organization sponsoring the development effort.

Each development effort should be clear about what constitutes benefit to their organization. For most of organizations benefit will be money, profit, dollars, pounds or some other currency. But benefit might be measured some other way. For a charity it might be how many people have clean drinking water, for a hospital it might be lives saved and for a school it could be attainment grades.

(Strictly speaking the terms "value" and "benefit" are different: "value" implies a hard number, "benefit" is a better description because "benefit" allows for non-financial outcomes. In general conversation the two are synonymous. But, perhaps because a hard number or because value is shorter to write and say, "value" tends to be used more.)

Those who worship at the alter of projects would have us believe that delivering on schedule, budget and quality will unlock the value promised by the project. After all, isn't that why a companies require business cases before work on the project began?

In fact two assumptions underlay the project model and these criteria:

• Benefit is known before work starts (which implies the benefit is knowable in advance.)
• There is no value in flexibility.

(Leave aside the question of how one knows what the value is and whether determining that benefit should have been part of the project in the first place.)

In a world where computing power doubles every two years, where both technology and business are in a constant state of flux and where every loft and garage seems to contain a disruptive start-up is it really possible to know the benefit of work in advance?

Projects set out to deliver predetermined functionality in a pre-determined time with pre-determined resources. Modern business is constantly changing, indeed the tension between business's desire for predictability and the simultaneous demand for flexibility undermines teams.

(In fact one of these criteria is itself ambiguous: quality. Some versions of the success troika say "requested feature" while others say "required quality." Some people even equate quality with features, as if more features makes for better software. A discussion of software quality is worth an essay in its own right but I must save that for another day.)

It gets worse.

These faulty assumptions lead to the faulty success criteria. These simple, concrete, success criteria become the goal of the work rather than the original goals. The original goals are often hard to define, hard to attain, they are often intangible and difficult to measure. Far easier then to focus on the success troika.

Sociologist Robert Merton coined the term "Goal Displacement" to describe just this scenario. Rather than focus on the real goal of work - to deliver business benefit - work is focused on satisfying the success troika. People shelter behind these proxy aims and manage work towards the wrong goal. Organizations, processes and even job roles are designed to deliver lower value tangible goals instead of higher value intangible goals.

One shouldn't blame managers for this situation, all of us - even me! - at times give in to goal displacement. Rather than pursue the real goal, which might be difficult to achieve, people focus on some proxy. Unfortunately in chasing the proxy they miss the real goal.

Back in 2006 Professor John Ward at Cranfield University in the UK published a survey of IT managers in the UK and Benelux countries ("Delivering value from IS and IT investments"):

• 70% of managers believed they were failing to identify and quantify the benefits adequately.
• 38% of managers openly admitted to overstating project benefits in order to obtain funding. (One has to wonder about the other 62% who because of their honesty are less likely to get their genuine projects funded.)
• 80% of managers reported that the review and evaluation of completed projects is also inadequate due to the focus on whether the project achieved cost, time and quality objectives and not on whether the intended benefits are realized.

While the first two points are incriminating in their own right it is the third which it proves the damage of the traditional project success criteria: in effect 80% of managers see the traditional project success criteria as an obstacle.

This survey was conducted 10 years ago but these seems little reason to believe that a similar survey conducted today be much different. Certainly anecdotal reports suggest the situation is no better.

Extracting value

Look again at the thing that called "a project". The aim of the project originators is to create value by delivering the project. Goal displacement occurs in the gap between value identification and delivery because the goals of each activity are not the same as the overall goal:

• Success in value identification means identifying and communicating potential business value, and then getting a delivery project launched.
• Success in delivery means satisfying the success troika of schedule, cost and quality.

Yet the overall goal is to deliver value to the business, customers and users.

These activities need to be brought together in value seeking teams. Even where these activities are kept separate a value seeking delivery team can, within some limits, deliver more value than a team which focuses on the success troika.

Viewed through the lens that the agile software movement: a project is actually a number of units of work which will hopefully deliver value. Some of these might deliver value sooner and some later. Some may require more work and some less. Some deliver lots of value and some less. Some are time dependent - and loose value quickly - others are not, the value they generate remains the same whenever delivered.

In other words: a project is a large batch of things - lets call them features - each of which should contribute towards value. Since the world is still in motion and technology is changing the value of each item, and even the cost of each item, is in a constant state of flux.

Viewing a project as a large batch of work items makes it easy to apply return on investment, cost of delay and cost-benefit analysis at the item level rather than the project level. The project delivers the first large batch of work, but requests keep on coming, some more valuable some less. Just because the value was not seen before a particular "sign-off" date does not make it worth less.

Once individual items have their own value then each becomes independent. Creation, delivery and, most-importantly, post-delivery evaluation can occur even before work starts on other requests. This creates another feedback loop which can help refine requests and decide what to do next.

Figure 1 - 3 Feedback loops

Most agile teams will undertake a regular "show and tell" to obtain feedback on what they have built. The better teams have a second feedback loop, a retrospective to improve their own working. Relatively few teams implement the third feedback loop to ascertain the value and benefit that they are delivering. Focus on the success troika renders this loop redundant, even dangerous.

It shouldn't be surprising if that sounds familiar. The feedback idea is embedded in iterations, Deming's plan-do-check-act cycle and the Lean Startup build-measure-learn loop. What is less obvious is that such thinking is incompatible with the idea of a project which has a fixed amount of work and fixed dates. Project thinking discounts learning which happens after a "start date" and disparage's learning which endangers the notional "end date."

Requirements list frequently contain requests left over from previous work and "just in case" requests. When teams become value seeking, looking at the benefit of work requests and checking the value delivered then some, if not many, of the original project work requests will prove to be past their sell by date.

When teams become value seeking the project model breaks down. There is no guarantee that the initial work requests will get delivered, new ideas are encouraged and end dates become meaningless - why end if you can still deliver competitive value?

"Failure" becomes an important option. Why should a team continue working if it cannot deliver value?

A value seeking team fails when it delivers less value than it costs to operate. When this happens, the team may well reorientates itself and change their approach. A "failure" is a message and an opportunity to change, to pivot. If the team cannot find value then it should wind itself up.

Contrast this with a team focused on the success troika. They need not worry about whether their work delivers value. Their success is measured on schedule, cost and delivered items. Failure is a black mark which occurs when schedule slips, costs overrun or deliveries don't measure up.

The notion of "failure" becomes subjective. "Failure" is simply a label applied to stories that are told to explain what happened.

For example, imagine a traditional team which starts value seeking. The team starts a "project" - a pre-selected batch of requirement requests that is thought valuable. After a few weeks they find there is no value in this work and decide to abort the project. Is this a success or failure?

On traditional success criteria it has failed. But based on value - in this case costs not incurred in the pursuit of pointless work - the team has been a successful.

Today good "agile" teams often follow this model within the confines of the project model and project language. One might argue that: "if the teams are doing the right thing then what does it matter what words get used?" But the existence of the project mindset outside of these teams frequently hinders such team. More importantly the project mindset, and language, creates dissonance and tensions between the different groups operating on different mental models.

This tension becomes most apparent when governance and portfolio continues to be based on the project model. Teams success - even continued existence - is judged by criteria which are inappropriate.

Increasing value, reducing risk

Breaking projects down to their component pieces has another benefit. Not only does value increase but risk is reduced. Rather than projects being all or nothing end dates, do-or-not-do, with most risk at the end (tail loaded), the risk gets spread over a wider set of features and deliverables and time.

Imagine a project manager embarking on project A. The project is valued at $1,000,000 and his analysis tells him there is a 30% risk of failure. Thus the weighted risk is $300,000. To keep things simple I'll assume value and risk are spread equally across the whole project.

Now suppose he splits the project into two, project B worth $500,000 carries half the risk, 15%, and project C carries the other half of the value and risk. Now the weighted risk is: ($500,000 x 15%) + ($500,000 x 15%) = $75,000 + $75,000 = $150,000, i.e. risk is halved.

Next split the same work into five equal pieces, each of value $200,000 with 6% of the risk, $12,000 per piece. Now the total risk is $12,000 x 5 = $60,000. The greater the number of pieces the risk gets spread over the lower the total risk.

Figure 2 - Reduce risk by spreading it over more deliverables.

Bundling more work into projects may look like it good but it increases risk.

Projects don't fit software development

Clear the project model of management is a poor fit for software development but there is one more piece of evidence to consider:

"The PMI [Project Management Institute] defines a project by its two key characteristics: it is temporary and undertaken to create a product, service, or result that is unique."

And the PRINCE2 handbook - a UK Government sponsored standard - contains the following definition of a project:

"A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.

The problem is: projects are intended for temporary endeavours. The key characteristic of projects is: projects end. However software doesn't end, software which is successful is continues to change.

Software which has users will receive change requests: requests to fix problems, enhance the software and update it for changing business problems.

Software which is used will need to be moved to new technologies: new operating systems, new devices, the infrastructure it is built on will change and will need the software to change.

How much software that was never suppose to change again continues to change? Introduction of the Euro and the Y2K problem 16 years ago saw millions of lines of old code examined and changes. How much of this supposedly "finished" software is still in use today? How much is still changing?

Software is part of our infrastructure. Government social security systems and bank payment systems are the bridges and highways of the modern world. The world changes and our software must change.

Visit SourceForge, look at the products which get the most downloads, they also have recent changes applied. Look at the software which nobody downloads, in most cases it won't have changed for months or years. Software which gets used demands change.

The only software which doesn't change is dead software.

Stopping software from changing is a fast way to kill it.

Treating software development as a temporary endeavour kills it.

Regarding software as temporary also means the teams which create it get regarded as temporary. Such teams get disbanded at "the end". The developers scatter to the four winds and with them the shared understanding and knowledge of how the software works and how to change it gets lost.

Disbanding performing teams is worse than vandalism, I call it "corporate psychopathy".

Actually, although project managers and corporations run a mental model of temporary teams such teams are often kept together in defiance to the project model. Conflict arises because the model - and perhaps the business assumptions built on the model - is different to "the real world."

The temporary but not temporary tension creates more damaging conflict. A mental model based on "temporary" leads to short cuts and quality compromises which impedes later work.

Ironically, deadlines are useful, deadlines are a great way of organizing work, creating focus and motivating people. Artificial end dates positioned at unnatural times damage software quality.

Rather than ask "How long will this take?" ask "What is the date of maximum value?" and then "What can we build to capture as much of that value as possible?" Effort estimation may have a role in the discussion but it is secondary to business imperatives. Business dates should drive work, not effort estimates.

The quality problem

Predicating thinking on a faulty model has consequences. Perhaps the most damaging consequence of applying the project model to software is the creation of a quality problem.

The idea that project is a temporary undertaking is highly corrosive because it leads to short-term thinking. Because the project will be "done" one day and the aim is meeting a date. Any shortcut which reduces time is seen positively. Such short cuts frequently damage quality - bugs go unfixed, refactoring remains undone and "technical debt" piles up.

Thinking about what comes after the project gets discounted. Remaining issues and problems get left for follow on "projects" and teams to deal with. Any consideration given to these issues is a luxury which gets dropped all too easily.

Unfortunately making these cuts is very damaging for the technical team building the product. As engineers, many of these individuals will feel good when they do a "good job". Conversely, they loose motivation when asked to cut corners. Once motivation is gone a vicious circle begins, productivity falls, project thinking leads to more quality reductions to get back on schedule, work becomes more difficult - as developers work around bugs and poor design - motivation falls further and success becomes ever more distant.

A friend of mine visited a company where the project manager focused almost exclusively on the end date. She was constantly on the lookout for ways to shorten the schedule. But when it came to release time the same manager complained the technical team didn't want to work late or put in extra effort to make the release happen.

Is it any surprise if after months of being asked to cut-corners and endure compromises that engineers shrug their shoulders at crunch times and when problems arise?

Language problems

There are plenty of project aficionados who, if they have read this far, will object to many of the points I have made so far. They will correctly say:

• "Project managers do allow requirements to change, they do not stick doggedly to the initial requests". This is true, although not universal; there are plenty of project managers who accept that requirements change as they go.
• "Project managers do not needlessly disband team, they will fight to keep teams together". And again they are right - although again not universally so. Many project managers recognise that teams do projects, often on the same code base or product, and there is a similar project right behind this one.
• "Project managers are not stupid about value, they will seek out value and will sacrifice schedule, features and fight for resources if they think they can improve value". Yet again they are right - although yet again this stance is not universal.

In fact, plenty of enlightened project managers will find a way of doing the right thing no matter what project doctrine says they should do. But now there is another problem.

If project managers don't follow project doctrine then what do they follow? What do they manage?

If project don't doggedly stick to PMI and PRINCE2 type definitions of what "a project is" then what exactly is a project? And why are these people called "project managers"?

And if none of these conditions holds true then why are project managers trained in these definitions and approaches? What is the profession based on?

There is another conflict: between on the one hand what projects should be, the criteria used to recruit project managers, the training they receive and the tools they are given, and then, on the other hand, what happens "in the real world." The work of a good project manager can be quite different to the training they receive to do and the model that they should adhere to.

Intelligent individuals who hold project management positions can be placed in impossible positions. Their training and professional institutions, their employer, its processes and structure can conflict with the right actions. Is it any wonder that project managers get a bad press when they are placed in such conflicted positions?

It is not just project managers who encounter tension between what a project should be and what it frequently is. When I present the PMI definition to developers I am sometimes told: "I never knew that is what a project was." For a developer a project may well be a code base, or a project file that describes the build order, or just a menu option, "File->New->Project->Java."

Maybe the people who are called "project managers" would be better called "development managers." In which case, why not train these people to manage software development? Why not give them a mental model that works rather than one which is crippled?

The word "project" does not have universal meaning. Perhaps because the PMI style project model is such a bad fit for software development the term "project" has multiple meanings in our industry.

However the lack of common meaning itself creates tension. With a different definition come different success criteria which in turn imply different courses of action and outcomes. For example:

• If a project is source code base then success may mean longevity and code quality; failure would mean code nobody wants to work on.
• If a project is a stream of ongoing work then success means happy customers and continued investment; failure would be falling customer numbers and reduced investment.
• If a project is a value seeking team working on a business opportunity success is value delivered and improved business processes or products; failure would be reoccurring costs greater than the returned value.

How one defines "a project" determines how success and failure are assessed. When different team members use different definitions there is no shared goal.

Many teams work not so much on projects as "false projects": development endeavours which use the language of projects but do not follow the project model. Language that should bring shared understanding brings conflict and confusion.

If any project aficionado has read this far they may well be screaming "you are talking about product oriented companies!" Educated project managers recognise that an alternative model of an ongoing product which does not conform to the project model. They are right, the world I describe is a product world but... the project model has become de rigueur in organizations and is applied almost universally. Even organizations which recognise themselves as product operations employ project managers.

Many organizations and teams are already beyond projects but they retain the language, paraphernalia and fripperies of projects (e.g. employees with the title of "Project Manager"). The project model complicates straight thinking. Removing the language and model actually simplifies reasoning and managing.

Diseconomies of scale

Part of the problem with projects is that they are, almost by definition, large pieces of work. The administration of creating a project, getting it approved, bringing the resources together, making the resources work together effectively, and then at the end unwinding all the temporary structures means the project model only makes sense when projects are large.

Companies like projects, projects imply change and change implies growth. This is much more attractive than "business as usual." But the need for project to be large means small is not an option.

Unfortunately, software development lacks economies of scale. Time and time again doing things in the small is more efficient than doing them in the big.

Economies of scale exist when buying milk in the local supermarket. A two-litre carton will cost less than buying two one-litre cartons. The thinking permeates each and everyone of us whether one studied it or not, economies of scale thinking is everywhere.

Yet economies of scale are rare in software development. Instead, diseconomies of scale are common. Large teams are less productive per day than small teams, changing (and fixing) 1,000 line program is far easier than the same change in a 100,000 line program, multiple small stories get delivered faster a single big one. Experience of work in progress limits shows that doing less at any one time gets more done overall.

Software is cheapest in small quantities. One litre of software is less than half the price of two litres.

Small cartons of software are cheaper and less risky

In part the big-batch projects are an attempt to maximise the value of the most precious limited resource: senior management time. Getting time with a senior manager is difficult, their interests in discussing anything less than $10m negligible. So why bother them with small pieces of work? You are more likely to get a few minutes of their time to approve a $10m project than to discuss 100 $100,000 pieces of work.

For software development to exploit the rampant diseconomies of scale, decision authority needs devolving downward so small decisions get made efficiently when needed rather than batched up into single big decisions.

How do we get out of this mess?

Despite all these problems, and despite the need for a big fix, there are some things that individuals can do now to improve the situation.

1. Stop staying "project"

Simply ridding yourself of the language of project is a good start. The word itself causes confusion because it brings assumptions and models into play which are not true. So stop using the vocabulary of projects.

Where the vocabulary cannot be removed, the different parties need to agree what is meant by the term "project." (It may help to invent new language to describe what the team does.) In defining what a "project", is it helps to agree shared success criteria - rather than having each individual make their own assumptions.

2. Public success criteria

For any work your team is undertaking be sure the objectives and success criteria are clear. Go further and make sure these are very public - post these objectives on a wall where everyone can see them!

When goals are intangible teams need to find ways to make them tangible. Conversations about benefits and value need to continue throughout the work, because the goal itself is hard to pin down.

3. Collections of small things

Stop seeing "projects" as large all or nothing endeavours, instead see them as a collection of lots of little things.

4. Value estimates

For each of these little things, have a statement or estimate of value. Estimates are good enough here, they can drive prioritisation. Once you have a value on the work item, consider how the value may change over time, if you do it sooner does it add value? How does value change when work gets delayed?

When value estimates are in place, you can also start to evaluate the post delivery result to create another feedback loop. Use the results of this feedback to calibrate future value estimates.

These suggestions might not come as a surprise to those versed in Agile. They parallel advice that has circulated for years. However here I am applying the advice at the next level up. Rather than thinking of "agile project" and doing all the good "agile stuff" within the project, I am suggesting the organization changes how it understand at work altogether.

Some of these suggestions lock together. For example, if you keep your teams together it is easier to do lots of little things. If you break your team up after every little job you will never have a productive team and management will spend all the time scheduling people. Instead have standing teams and bring the work to the team.

Mental changes

The changes I just listed can be done immediately. They are things you can start doing right now by yourself. Going further means changing not just your own mental model, but the mental models of those around you. As the Keynes quote I opened with says, practical men need to free themselves of an outdated idea.

Given that project thinking has dominated the approach of management for the last 30 years, moving away from projects is going to require some changes in management thinking.

1. Put dynamic value centre stage

Be clear about what value your work is intended to deliver and how the work will build value. Put value rather than schedule, budget and features at the heart of all decisions.

Recognise that value changes over time. Individual requests will have different values at different times and as time progresses the value profile will change. Add in a changing world and changing technology and it becomes clear that value needs to be actively managed.

2. Project is not the only fruit

There needs to be recognition that projects are not the only way to organise work. Rather than a stop-go approach a continual steady state needs cultivating. Call it "product orientation" or "business as usual" mindset. Modern businesses are dependent on software so organizing to be good at creating software has business benefits.

Continuous flow, continuous improvement and continuous delivery are not temporary. Benefit needs to be continuous too.

3. Optimise for small

Work processes need to be optimised for small pieces of work - small batch sizes, and small items. This means big activities (e.g. setup, teardown, one off reviews) need to be removed. Things which are expensive and which get minimised (like sign-off and final test cycles) need removing or rethinking so they can be efficient in the small.

Each of those small pieces of work needs to demonstrate potential value and then get evaluated afterwards for value delivered.

4. Optimise decisions for small

Critically optimising for small work requests means decision-making also needs optimising for small. A model where a few people at the top make a few big decisions needs to give way to devolved authority where people close to the work make the decisions needed as the work progresses. This might mean devolving authority to those who do the work - coders, testers, etc. - or it might mean that managers close to the work need more authority and autonomy.

5. Stable teams

Once you start seeing projects as a collection of small things, it is natural to centre future planning on the team. Stable teams help with such planning unfortunately they also go against project thinking. However, the problems of constantly forming and disbanding teams means that many teams are already, by default, stable. It is just that mentally they are seen as temporary.

6. Flip control

Devolving decisions and focusing on value does not mean giving up control, far from it, but the model of control needs retiming. Rather than spending lots of time deciding what should be done and authorising work to happen, teams need authority to do what they find is best.

Such changes follow the same logic found in the "Beyond Budgets" movement. Rather than measure progress against a plan or budget, employees are trusted to do the right thing and know they will be judged by the result, not by some proxy yardstick.

Governance and portfolio management processes need to trail the work. Rather than looking forward at what is predicted to happen (which has a poor track record) governance looks at what did happen, specifically how much value was actually delivered.

This may sound counter intuitive, and so it is when work packages are large, but when work is small then how much damage can be done? Two wasted weeks might not be good but how much time is lost waiting for decisions? Evaluating proposals? Gaining work authorisations? And how much money is lost by late delivery?

When development work was slow (think Cobol) and expensive (think mainframes) then it made sense to ensure that nothing wrong was done. But in a world where development is fast (think Ruby) and cheap (think cloud) the cost of doing analysis, and time lost in governance and delay, is far greater.

In such a world, it is preferable to spend a little bit of money and later find out the money was wasted rather than: spending a more money and time to ensure that no money at all is spent on activities which might turn out to be wasteful. The cost of determining what expenditure is waste and what is beneficial can itself be greater than the potential waste.

Project management tools of analysis and authorisation continue to take time. Today's technology allows us to build solutions and try them in less time than it takes to agree formal sign-off for work. It takes too long to set up temporary teams and tear them down.

And that is all before even considering the value of what might be learned as a by-product of doing something wasteful!

7. Tolerate failure

It should be obvious from the last point, but it is worth emphasising. Sometimes things will go wrong. Sometimes development efforts will not deliver value.

The software industry has a poor track record of determining where value is and how long it will take to deliver that value. Rather than expending more time and energy on soothsaying it is now cheaper to tolerate some cheap and faster to tolerate a few little failures.

Technology has advanced, technologically the tools exist now the process and management models in use also need updating.

Even when work look like failure, failure is subjective. Work may not deliver the intended value but still deliver useful learning: about technology, about the market, about "what works."

Companies need to be tolerant of failure, and when it does happen, they need to salvage what they can and move on.

8. Deadline not end dates

Finally, while pre-determined end-dates are a thing of the past deadlines should not be. Use deadlines to your advantage but let end dates emerge naturally.

Humans are very bad at estimation but very good at meeting deadlines - even if the work is done the night before. Teams can harness this foible to their advantage.

Value is not simple

Removing the project model from your mental model will certainly simplify thinking but it is no cure all. Managing software development is still hard.

One problem that is certain to appear is the definition of value.

I have argued that the success criteria used by the project model should be replaced with a focus on value. But what is value?

In order to focus on value, one needs to understand it. Unfortunately that is easier to say than do. Value exists within a context. As already noted value varies over time, for any given feature early deliver may hold a different, higher or lower, value than later delivery.

But there is more to it than that. Value is also related to the business model and strategy of the organization. For a business attempting to grab market share the "value" of more eyeballs visiting the site, or more sales to new customers, may have greater value than repeat business to existing customers. Yet for a company targeting higher profit margins the opposite may be true.

To complicate matters, different people might have different views on what constitutes value. Boiling "value" down to a single number or target is not only hard but can be counterproductive. Customers, business and strategy can have multiple aims; "value" can be multifaceted.

When talking about "value" it is easy to fall into the trap of thinking value is a number and that higher is better. It is easy to think higher revenue and profit, or lower costs, are represent more value but this is not true.

Measuring value in the information economy is hard, in fact it is an active research area for academics. Consider all the searches on Google, what value are they? In traditional terms they add nothing to the bottom line, all the millions of Google searches fail to register on the official statistics of any country because Google does not charge for search.

How can you measure the value of improvements when your company offers services for free?

Even when measurements are possible there is a well-known lag effect between IT changes and productivity benefits appearing. During the 1990's economists wrestled with the "Productivity Paradox" described by Robert Solow as "You can see the computer age everywhere except the productivity statistics."

Then there is an attribution problem: if your new software allows the company to change their customer service processes then how much of the benefit is due to the software and how much to the new process? Indeed, extracting the maximum value from technology involves more than just creating the new technology. It is well know training users can help but so can changing the culture, pushing authority down to front line workers, changing performance incentives and recruitment criteria. Again, these changes can take time.

(For a longer decision on some of these issues see "Wired for Innovation", Brynjolfsson and Saunders, 2010.)

Faced with these difficulties, it is easy to see the attraction of the project success troika which allows problems of value to become "somebody else problem". The first step in considering "what is value" is simply to start having the conversations. Ask the question in the team, ask the question of those around the team, start making suggestions and taking feedback.

Understanding value and benefit requires a feedback loop. As changes and improvements are made they need to be evaluated to see what benefit was delivered: Could more benefit be unlocked by supportive changes? How can benefits be accelerated? Should more similar work be undertaken if benefits cannot be realised?

There is more to maximising the benefits delivered from IT than simply delivering the technology. Rather than throw benefits delivery over the wall to another group, teams need to be aware of the issues and integrate value thinking into their processes.

Value can be simple, but simplistic thinking about measuring value and benefits creates its own problems. The danger is that the pursuit of simplistic value itself displaces the real goal of creating real value.

Conclusion

When I attended the Lean Agile Scotland conference to deliver the #NoProjects presentation I met a group of people from an Edinburgh financial services company. This group couldn't consider work without projects. Yet when I quizzed them I discovered that the same people had worked on the same software codebase, on the same mainframe, to serve the same customers for over a decade. One project followed another, the only thing that was temporary about their work were the end dates.

At times our industry, indeed perhaps all modern management, seems to revolve around "projects" as if they are an inherently natural phenomenon, they are not. Projects are a twentieth century invention that has outlived its usefulness. The project model sidelines business benefit because it chases the wrong goals in the wrong way. Traditional project planning is not a harmless, benign, past time. It is dangerous, it reduces value and increases risk.

The project model does not describe the world of software development. Forcing software development into the project model requires so much mental energy, compromise and workarounds that it becomes impossible to see what is really happening.

Managers and engineers who cling to the project model to describe their work are like aircraft ground crew who use manuals for a Supermarine Spitfire to service Lockheed F-35 Lightning: both are agile single seat fighters with wings, but that is where the similarity ends.

Nowhere is this mismatch more apparent than in teams who practice continuous delivery. Such teams will inevitably abandon the project model, a model made for a temporary world, and continual is not temporary.

Related Software Projects Management articles

#NoEstimates - Alternative to Estimate-Driven Software Development

Kanban for Skeptics

---

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2016 issue of Methods & Tools