Planning and Monitoring Investment (FKA “Estimation”)

“How much will that cost?” is a tricky question. Depending on the context (particularly the absence of a fixed-price binding contract) it is often an unfair question and usually a naive question – but it’s also a question we need to expect; if those paying for products or services don’t try to understand what they can expect to get for what sort of money then everyone’s heading towards some major frustration. The question needs careful management.

So, how much will that cost? Unfortunately a short answer is usually expected; unfortunately a short answer is usually supplied in the form of a price (or price range) with unspecified reliability, to provide an inadequately specified outcome under unspecified conditions based on inadequately specified assumptions without consideration of risks. It’s known as “the estimate” (often misheard by the customer as “the cost”). The estimate contains the hopes of the customer and the (entirely different) hopes of the supplier. The difference between these two sets of hopes is likely to be the source of conflict between customer and supplier at some point in the future.

What’s actually needed is not the “estimate” or the “cost” but an open and ongoing discussion between customer and supplier about how the customer’s investment can be most effectively planned and then monitored. Estimation is part of this discussion.

So how do we manage this discussion? I think it’s helpful to think in terms of different levels of planning and monitoring, with the right level being determined by our proximity to the detail of the work required. The three levels I like are:

1. Contextualisation
2. Rationalisation
3. Evolution

It should be the customer that decides, with advice from the supplier, what amount of effort should be spent on what level of estimation, at what points in the project.

1. “Contextualisation”

“Contextualisation” is the highest level of estimation. It should occur prior to budget confirmation and prior to any design or any code being written. This is the sort of estimation that helps support a business case: can the products intended to meet the business needs/opportunities be created with an investment that represents value for money vis-à-vis the expected business benefits? It provides some context re sort of ambition and cost expectations that we’re dealing with.

Four steps make up “contextualisation”. They could be formal and lengthy, or could be completed verbally in one meeting – whatever is right depending on the nature of the proposed work.

a. What is this project trying to achieve? Business provides (with supplier help if appropriate) whichever of the following it can:

• Primary objective or vision
• Indication of ambition (investment available, revenue targets, existing market examples to be emulated/avoided, etc).
• Top Ten high-level requirements (taking into account NFRs, essential characteristics, architecturally influential factors)
• Attitude towards date, cost and scope/spec/bells&whistles/gold-plating/performance (are any fixed? How fixed?)
• Indication of minimum marketable feature set f. Likely user categories

b. What kind of Contextualising estimate is appropriate?

Customer and Supplier agree:

• Whether the Contextualising estimate should cover everything we can imaging wanting, or whether we just want a contextualising estimate for the first release, or both, or some other subset of “everything”.
• Target margins of error for the estimate(s)
• Who will do the estimating, how much effort this will require and how the effort will be paid for.
• Date for providing the estimate(s)

c. Creation of Contextualising estimate

Supplier provides:

• Contextualising estimate(s), to the terms agreed in 2.
• Assumptions on which the estimate(s) is/are based, key risks.

d. Business and Supplier discuss:

• The basis for the Contextualising estimate, including the assumptions and keys risks identified by the supplier
• (Assuming the Contextualisation estimate has not lead to the conclusion the project isn’t viable and will be abandoned) How “Rationalisation” and “Evolutionary” estimates will subsequently be managed over the course of the project.

Who on the supplier side will do the “Contextualisation”?

Those who are most qualified based on knowledge and experience (and who are available) – which means not necessarily those who will be responsible for designing, building, testing and implementing the products. “Contextualisation” takes place pre-project, so often the project team won’t be known. The project team will provide project-level estimates (“rationalisation” and “evolutionary”) later.

It’s important that estimation is not solely about technology (eg complexity of contractual negotiations)

Who pays?

“Contextualisation” level estimation can’t come from project costs as it’s a pre-project activity.

2. “Rationalisation”

“Rational” estimation requires effort from the team who’ll be creating the products. It is based on business and user needs being expressed as user stories, and user stories being assessed for complexity and effort. It brings a rationale to the high-level “contextualising” estimate.

The scope of the estimate needs to be agreed in advance with the customer (probably will cover all known requirements to first release but could for example expand to all expected “must” and “should” requirements as far as the horizon) – it depends how the customer wants the effort spent and what sort of certainty the customer needs.

A margin of error or expression of certainty is provided alongside lists of assumptions and risks (revised from the kick-off document, reflecting what’s been learnt in the interim).

A release-level burn up/down chart might be produced (the less change to scope is expected the more valuable a release-level burn up/down chart will be).

The project team should begin real work alongside producing the “rational” estimation; the reason for this isn’t so much the intrinsic value of the code or designs produced, but the learning (relevant to estimation) gained by going through the steps required to start real production.

Who pays?

“Rationalisation” is part of the project team’s effort, therefore is part of the cost of the project. Every hour spent estimating is an hour not coding or designing or testing – so it’s important the effort, purpose and margin of error are agreed in advance with the customer.

3. “Evolution” (Monitoring the investment)

“Evolution” is the practice of inspecting and adapting: each time something is learnt that affects the release and/or project estimate (revised velocity, changes to number and complexity of tasks required to complete a story, changes to product backlog, changes to dev team, etc) the estimates are adapted accordingly. The sort of lessons that might have an impact on release (and/or project) estimates are likely to be come out in sprint retrospectives (ie they require no dedicated additional effort). Defining the nature of that impact on the rest of the release and the rest of the project takes effort that again needs to be discussed and agreed with the customer. “Evolutionary” estimates might be issued at the same frequency as sprints, but this needs to be discussed and agreed with the customer.

Ultimately it should be the decision of the customer, advised by the suppliers, as to how much effort should be spent monitoring the investment.

Up-front analysis – the Agile way!

Some agile practitioners exhibit a sort of zealousness that characterises the recent convert, so that anything that might have even the slightest whiff of old-school/traditional/waterfall/dinosaur project management is seized upon, exaggerated and trounced, usually with sarcasm.

Estimation, documentation and process are three popular targets for derision, but the favourite is surely “up-front analysis”.

And often rightly so. If “up-front analysis” means spending a substantial proportion of budget, prior to any design or code, trying to identify every last need that must be addressed and every little featurette that a complete system/product must deliver, then I’m first in line to denounce it.

But this doesn’t mean we must denounce any and all up-front or pre-build work. In fact I staunchly believe that the right highly focussed up-front work is one of the most valuable, arguably one of the “most agile”, of all activities.

Highly focussed, highly valuable up-front work simply means ensuring customers, users and suppliers understand (before coding begins)…

• why the business is investing
• how value-for-money will be understood
• who’ll be doing what
• how much is currently expected about what the products will look like
• who’ll be affected by those products
• current attitudes towards time-scales
• who needs to be kept informed of what
• who gets it in the neck if delivery fails to meet expectations
• how the products will be run once they’re released

There is nothing predictive about the facts being collected, they simply summarise what is understood before work commences. Little or no analysis is involved, just some leg-work and a bit of thought about what we’re trying to achieve and the approach we’re going to take. This work should take as little effort (provide as little detail) as possible to be effective, and as much effort (provide as much detail) as necessary to be effective in light of the level of investment.

To avoid Pavlovian responses to the up-tight expression “up-front”, I usually use “kick-off” when referring to this pre-coding work.

The objective is a collection of highly relevant facts that would in most cases fit on the back of an envelope. And so I also advocate we write-up what’s been agreed, creating a “kick-off document” (cue howls of derision).

More on the “kick-off document” in my earlier post

A new project triangle: Time, Cost and 5-Dimensional Product

The project triangle addresses the premise that a project has three dimensions, at least one of which must have some flexibility. It is, effectively, a pre-requisite for high-level prioritisation and release planning. Nearly all depictions of the project triangle have Time and Cost as two of the corners. There’s less consistency when it comes to what the third corner is all about. I think there’s a good reason for this: the third corner is complicated. Just as the project triangle is about considering and confirming the business’ tolerance for movement across the three dimensions, I think the third corner is also made up of several dimensions, each of which needs to have been considered before we can make informed decisions about prioritisation throughout the rest of the product development lifecycle.

The third corner is sometimes known as “scope” and sometimes known as “quality”.

Whether we go for “Scope” or “Quality”, either is unsatisfactory, as neither term adequately conveys the complexity of that third corner – and because the words “Scope” and “Quality” mean different things to different people (which has greater quality, a chain of steel or string of pearls?).

The “project tetrahedron” tries to accommodate both “Scope” and “Quality”. This is also unsatisfactory, primarily because “Scope” and “Quality” are simplistic and again ambiguous terms.

In practice what we’re trying to find is the right balance between Cost, Time, and a bunch of other things more complex than just “scope” and/or “quality”, that taken together define what product or outcome is desired. So the third corner of the planning triangle should be known not as “Scope” or as “Quality” but as “Product”.

Now, if we know from the outset exactly what the product/outcome needs to be, then a simple triangle would suffice, the Product corner would be fixed and Time and Cost would need to be flexible. But in practice we usually can’t guarantee at the outset exactly what the product needs to be.

What we can know is the business’ tolerance for change or flexibility that can be applied to each of the dimensions that comprise the product.

I propose there are probably five useful, manageable dimensions to product:

• Scope This is what’s within our remit and, usually much more usefully, what is not within our remit. “Scope” is usually applied to business requirements, objectives, success criteria, etc rather than directly to the products. “Scope” is the boundary within which we expect the product(s) to exist, regardless of the quality or detail of the delivered products.
• Feature set is the large-grain components that collectively are expected to make up the product.
• Bells & whistles are the finer-grained, more discretionary components; they might make things more fun, or accommodate more scenarios, or provide more options.
• Gold plating is the discretionary side of quality, the nice, unnecessary, welcome and often brand-based touches.
• Performance is the other (less discretionary) side of quality: the standards that must be met, the weight/pressure/volumes that must be borne, the capacity that must be delivered.

Once we look at our product as a combination of these five dimensions it becomes easier to see how the “product” corner of the triangle can have flexibility just as Time and Cost can have flexibility. In the context of the planning triangle, statements like “Scope is fixed” or “Quality can’t be compromised” are too simplistic.

Thinking in terms of a product corner made of several dimensions also sets a framework for future ongoing prioritisation. When we write users stories and plan sprints we are thinking through these product dimensions (whether or not we explicitly acknowledge them as such). I’m sure the developers and the business can work together more effectively if these dimensions are clearly articulated, particularly at the early stages.

Thinking in terms of a product corner made of several dimensions also makes a significant contribution to defining the criteria to be met by a first live release.

8 basic areas for project kick-off

I’m a big fan of Agile thinking, so I’m also a big fan of up-front thinking – as long as it’s light-touch and rigorous. Up-front and Agile? Yep. This is to avoid the scenario in which the dev team and the business are inseparable in their mutual respect and shared desire (hurray!) to deliver value for money (great!) while using all the leanest, extremest, scrummiest tools and techniques (cool!)… only to go in circles (aargh) because no-one dared commit to some fundamental principles up front (doh).

Ultimately this is about customers, users and suppliers understanding (before coding begins) why the business is investing, how value-for-money will be understood, who’ll be doing what, how much is expected about what the products will look like, who’ll be affected by those products, how much flexibility there is around time-scales, who needs to be kept informed of what, who gets it in the neck if delivery fails to meet expectations, and who’s going to run the products once they’re released.

This is a collection of highly relevant facts that would in most cases fit on the back of an envelope. Little or no analysis is involved, just some leg-work and a bit of thought about what we’re trying to achieve and the approach we’re going to take, and writing up what’s been agreed.

There is nothing predictive about the facts being collected, they simply summarise what is understood before work commences.

This upfront work should take as little effort (provide as little detail) as possible to be effective, and as much effort (provide as much detail) as necessary to be effective. The person responsible for kick-off needs to judge what level of detail is right in proportion to the investment.

I think project kick-off should consider eight basic areas:

1. (Re)State the business case: the reason we are going to create the products. The Business case should state:

• The business needs or opportunities that the project’s products are intended to meet
• The investment rationale (what would constitute value for money; in some cases this might be stated in very broad terms).
• Key risks and dependencies

2. Establish user categories and their respective needs (high-level user requirements and constraints) and agree how user interests will be represented throughout the project lifecycle. The emphasis here is on establishing who are the relevant users beyond the obvious categories of the business and the end user.

3. Establish the business’ attitude towards time, cost and product (scope/spec/bells&whistles/gold-plating/performance). This might be expressed as priorities and/or as tolerances and might include a possible release schedule (either relative or absolute dates).

4. Outline the product(s) that is/are expected to meet user needs. At this point it could be as hi-level as “bridge, or boat?”, or might be more granular. This might have been sufficiently covered by point 3, above.

5. Agree a framework that ensures development proceeds and continues with the customer’s informed consent to spend. The customer and the project team need a shared view of how the investment can be most effectively planned and monitored. What effort should be spent now to estimate what? With what level of certainty? What effort should be spent throughout the project to estimate what, at what milestones, with what level of certainty? What effort should be spent throughout the project assessing the impact that emerging knowledge has on time, cost and product?

6. Establish how the project will be organised. The basis for project organisation should be ensuring certain key areas are each allocated an accountable owner. I’m currently in favour of nine “key areas” that I think are essential to most design and build projects, though I can imagine variations on this that would be just as effective or possibly more effective. I’ll provide more detail on the nine “key areas” in a future post.

7. Outline how project and product status will be communicated. This might be sufficiently covered by project organisation.

8. Outline provision for running/supporting products from first live release.

Kick-off might also include:

• Outlining the practices expected to be used by design & build team(s). This might have been adequately covered by organisation and communication.
• Refinement of the business case in light of lessons learned while compiling kick-off information.

The nature of the project will determine how much effort is required to complete project kick-off.

Project kick-off is actually nothing more than a check-list: before design and build begins there are these basic areas that should have been thought through, and the outcome should have been compiled in a project kick-off document.

The project kick-off document sets out what is known and agreed at the beginning of the project.

It has no role in dictating how the project will then unfold and evolve.

Whether or how the document will be revised and baselined to reflect ongoing evolution is for the business owner to decide.

More on this in my subsequent post, Up-front Analysis – the Agile way!

Agile project management in non-agile environments

An end-to-end agile environment rarely exists. We should not ignore this, deny this, be distracted by this, or seek excuses in this. We should acknowledge and manage this.

While the dev team might have deep understanding of and passion for agile practices and an agile mindset, their products and practices will usually have to interface with a non-agile world at some point, like…

• Interdependencies between software development and non-agile workstreams (legal, commercial, marketing, internationalisation)
• External product suppliers working towards a single final delivery
• Commissioners who fear losing those parts of their budgets that aren’t unambiguously committed

Three possible responses to this:

• Blast ahead developing in an agile way in the full knowledge that the corporation doesn’t have a clue what this means and the person you’ve identified as sponsor or business owner is paying lip service when he/she assures you you’ll get as much of his/her time and attention as you’ll need.

• Manage a change of the entire corporate culture over to agile thinking

• Manage the agile/non-agile interfaces

The first seems like the most ridiculous option but is in my experience the most frequently adopted. Unfortunately the result is the very us-against-them mentality that the Agile Manifesto urges us to dissolve. The devs caricature “management” as being dinosaurs who clearly don’t care about the project; management caricatures the devs as never saying what they’re going to deliver or when they’re going to deliver it or how much it’s going to cost. It can lead to a tension and mistrust that’s far more destructive and wasteful than the much-maligned contract-based supplier/client relationship.

The second is the ideal (or idealistic) solution, but at best could take several years to mature into effectiveness and requires specialist skills (not development or delivery management skills). We can advocate this change and do what we can to provide practical support – but in the (partially-agile) meantime products need to be designed, developed and delivered. If we’re willing to advocate the fit-for-purpose product in favour of the perfect product, we shouldn’t insist on an idealist attitude towards corporate management structure and mindset. We need to be pragmatic and work with what we’ve got.

The third is the pragmatic response – and is well within our skillset as Delivery Managers and consultants.

So how do we mange the agile/non-agile interfaces? I expect to address this in a future post.