project management

Tractors, nuclear powerplants and the bleeding edge

It is common for organisations to select a major technology leader (such as IBM or Oracle) and ride their product development cycle.  On client I worked for stated that they would:

“not follow a ‘best-of-breed’ approach, but rather select a major technology leader (IBM)… This means we explicitly seek and accept the “80% solution” rather than trying to optimise for each and every possible requirement. …Shortcomings will be made explicit in order that we can escalate with IBM, and influence their product strategy”.

Influence the IBM product strategy.  Good luck.  This one-size-fits all approach to technology maybe appealing on paper, and certainly has its benefits, you recruit a certain type of developer who has skills in that technology stack, if you are big enough your buying power may get a small voice in future releases that you will pay through the nose for.  But is it the best approach for the business?  A colleague, Stuart Hogg, takes three metaphors for enterprise IT.  The tractor, the nuclear power plant and the bleeding edge.

The tractor. This is the technology that keeps the lights on.  It is commodity software, it is the HR system, email, intranet etc.

Nuclear powerplant. This is the (generally bespoke) mission critical software that drives the business.

The Bleeding edge. This is the platform where you do cutting edge stuff, test and learn.  The ideas may one day be migrated to the nuclear powerplant.

All too many organisations get confused between these three models, loose sight of where they should be investing and plump for a one-size-fits-all technology to do all three.  Thus we see tractor technology trying to do the bleeding edge (Is it possible to innovate at speed with those Big Enterprise Solutions?)  By trying to combine utilitarian computing with strategic and speculative innovation, using the same skillsets, timeframes, processes and models, IT will never truly deliver the value for which it is capable.  Another ThoughtWorker, Ross Petit reiterates this point using a banking metaphor of utilitarian retail banking and speculative investment banking. He divides IT into “utility”, around 70 percent of IT investment (tractor and the nuclear powerplant); and “value add” the other (bleeding edge)30 percent.   Like other utilities such as electricity and water, ‘you don’t typically provide your own. You plug into a utility service that provides it for you’.  In IT that means SAAS and outsourcing and taking a strategic decision to differentiate between the different functions that IT performs.  He concludes:

Separating utility from value add will make IT a better performing part of the business. Because they’re comingled today, we project characteristics of “investment” into what are really utilities, and in the process we squandor capital. Conversely, and to ITs disadvantage, we project a great deal of “utility” into the things that are really investments, which impairs returns.

As a business function, IT has no definition on its own. It only has definition as part of a business, which means it needs to be run as a business. The risk tolerance, management, capabilities, retention risks, governance and business objectives of these two functions are vastly different. Indeed, the “business technologist” of value added IT needs a vastly different set of skills, capability, and aptitude than she or he generally has today. Clearly, they’re vastly different businesses, and should be directed accordingly.

Separating the utility from the value add allows us to reduce cost without jeopardizing accessibility to utility functions, and simultaneously build capability to maximize technology investments. Running them as entirely different business units, managed to a different set of hiring expectations, performance goals, incentive and reward systems, will equip each to better fulfill the objectives that maximize their business impact.

About a successful project that was a failiure

On time, on budget, to the scope that was agreed from the outset of development.  A successful project?  Well no actually.  It was a complete failure.

Here is a story about an insurance company with a number of differnet products sold through intermediaries.  Whilst the intermediaries were good at selling single insurance products, they weren’t so good at cross-selling or up-selling other products.  Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.

What if the intermediaries could have a portal where they could access all our insurance products in the same place with customer alerts and sales support prompts identifying further selling opportunities?

From this initial idea a benefits case was pulled together consisting of a product definition and financial projections.  In pulling together the benefits case, the potential revenue uplift numbers surprised everyone.  Signing off the benefits case on the new Intermediary Portal was duly signed off, and the product definition was handed over to IT to build.

Being an agile IT shop, the business and developers sat down together and got their heads around the product definition.  It soon became clear that the challenge was one of “single sign-on”.  Each of the insurance products offered were on a different legacy application that required the intermediaries to sign-on with different credentials.  To bring them all together in a single portal was far harder than the simple problem that the initial product definition suggested.

In pulling together the benefits case, a rough estimate had been supplied by IT. Now it was an in-flight project with an initial list of stories, it became clear that they had significantly under-estimated.   Of the twenty different products that the business wanted on the portal, for the budget the business had set aside would deliver barely four products.

With new estimates a release plan was drawn up.  Release one would deliver single sign-on across four products identified by the business as being most profitable.  All the  sales support tools were de-scoped and scheduled for a third release with the second release delivering single sign-on for the remaining products.

Development started, the business stakeholders worked closely with the developers and the First Release of the Intermediary Portal went live with congratulations all round.  Funding for the next release was lined up depending upon the success of the first release.  But that success never came, take-up was less than expected and the cross and up-selling never materialised.

The proposition to the intermediaries as delivered was flawed; the portal had to be all or nothing, single sign-on across four unrelated products was not compelling to them.  There was no sales support.  The intermediaries thought “so what?”  IT had delivered on the business requirements yet the project was deemed a failure.

This story tells a striking lesson. The project failure was due to a lack of joined-up thinking.  The business and IT both had followed their processes and done the right thing.  The business had identified an opportunity, built a benefits case and had this signed off.  IT had run a model agile project with close engagement with the business.  However whilst both stages of the process were locally optimised, they were done in isolation of each other.  Once the (development) train had left the station both sides were committed to delivering the product portal.  No-one returned to the business case, no-one went back to the end users, the intermediaries and asked whether the cut down scope for the first release would actually be of value to them.  More importantly, IT were engaged too late in the process.  The business had settled on an IT solution to the problem without engaging IT.  Had IT been party to the ideation and visioning process they would have been able to raise the risk of the project complexity earlier on.  Indeed they could have killed the project before it started.

Returning to the initial problem; “intermediaries weren’t so good at cross-selling or up-selling other products… Focus groups with the intermediaries revealed that they didn’t know about all the other types of insurance available through the company.”  The problem didn’t need a portal solution. The issue was one of awareness; almost certainly an off-line marketing campaign would have delivered a greater ROI without the need for IT to build the wrong product.

A picture tells a thousand words. So prioritize pictures not words

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

You need to accelerate and change gear to get up to speed

Velocity is a simple concept to grasp when planning and managing an agile project.  It is one of the first formula you learn in maths (or is it physics), speed equals distance over time.  On a project the distance is scope, measured in the number of ‘points’ you need to complete.  So if the team has a hundred points worth of scope and a velocity of ten, they will complete distance (scope) in ten weeks.  It’s a simple calculation, but is dangerous and wrong.  It fails to take into account acceleration.

Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity.  To reach 60 miles an hour takes ten seconds and means moving through the gears.  You don’t put your foot on the accelerator and suddenly find yourself doing sixty.  Nor do you put the car into forth gear and expect to move without stalling.  It is the same in agile projects.  Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration.  Similarly, putting a fall sized team onto a project is like trying to start in forth gear.  You will stall.

When planning an agile project you need to consider acceleration.  The first iterations will be slow as you come up to speed.  Secondly you need to be in the right gear for where you are at.  Start in first (small team) and change gear (ramp the team up) as the velocity requires it.  Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.

Sadly, this means the simple pictures on burn-up and burn-down charts are wrong.  They need to take into consideration acceleration and appropriate gearing.  And that is advanced maths.

Are you managing expectations beyond the team?

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits.  Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers.  And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise.  The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release.  How are you managing expectations beyond the immediate product team?

Be wary of what you say early on.  Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future.  Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go.  Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team.  In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them.  This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

Have you considered the cost of context switching

One of the great things with running a project with Microsoft Project is that it enables you to allocate resources to activities and you can assign the time they work on each activity.  A resource can then work on several projects at the same time, 50% on project A, 50% on project B.

With this ability it is easier to accommodate multiple projects that the business request.  Rather than having to say we can’t start on a project in six months when the current one finishes, we can run both projects at the same time, using the same resources.  We can do things in parallel rather than in series.

Only it doesn’t really work like that.

One of the great things with running a project with Microsoft project is that it enables you to allocate resources in a way that hinders productivity, effective planning and quality.

The problem is with context switching and the overhead that multi-tasking brings.  This article succinctly describes the problem.

No matter how efficient you think you are, multitasking comes with a high cost. Because we’re people, we don’t swap out the content of our brains as easily as a computer does, and we definitely don’t swap in the old state when we’re ready to return to the original task.

Gerald Weinberg, in Quality Software Management, Vol. 1, Systems Thinking (Dorset House, 1992), estimates the context-switching cost among three tasks to be 40 percent. That means that 40 percent of your available work time is spent on non-task activities. The rest of the time is split among the three projects. So, if you thought that in a 45-hour week, you could spend 15 hours on each of three tasks, don’t kid yourself. You’re really spending eight hours on project A; eight hours on project B; eight hours on project C; and 24 hours context-switching, figuring out where you were and what you have to do next. The time spent on each project works out to about half of what you expected.

So whilst it is easy to appear to please business sponsors by taking multiple projects on at the same time, and the model of working in parallel rather than in series being a politically favourable approach, in fact the costs of multi-tasking far outweigh the benefits.

How long does it take to start. I mean really start?

Let’s assume that you are not bought into the whole agile thing.  That doesn’t mean you can’t look at your IT organisation and identify waste and fat in the process.  How long does it take from the business having an idea and requesting IT to build something to the developers actually starting to code?

This seems to be common: The initial ‘idea’ is fed into the PMO team, it is documented with a high level scope, rough business case and napkin estimate of +/- 100%.  Elapsed time (i.e. the time from the first email or conversation requesting the requirement through to the initial scope document being circulated and approved): two weeks, value added time (i.e. the time actually spent thinking, doing or deciding); two hours.  The project, having gained approval in principle, is then prioritised.  Some organisations actively monitor thier project protfolio, others do it annually, with the business having to put in project requests when the budgets are set.  Mid-cycle and the project is unlikely to take off.

Let’s assume PMO agree the value of the project, next step is high level design.  Analysts capture high level requirements, ascertain what the business really wants and refine the business case further.  IT puts some high level estimates against the requirements, with a +/- 80% confidence.  Elapsed time: eight weeks.  Value added time two weeks.  With a refined business case to take to PMO or the steering commitee all that has changed now is that we have some more detail and a guess on what it might cost.  We are ten weeks down the road and we still have not made a decision whether the project will commence.  This due dilligence is notionally about reducing risk and keeping costs in check, but in reality, what value has been added?

Now it is time for detailed design.  Another (elapsed time) eight weeks of analysis, drilling down into the requirements.  Documentation follows workshops, only now the specification is no longer speaking the language of the business.  Use cases, UML, it’s all getting slightly technical and the business are not really sure what they are reviewing.  Let’s call it another couple of weeks of actual value that is added.

Eighteen weeks elapsed time, countless meetings, momentum and still no decision on whether project will start, let alone a line of code being written.  But the business case is really taking shape and IT have got the estimates down to a 20% confidence limit.

The project gets the go-ahead, but it is not yet time to start coding.  Technical design needs to take place, four weeks of architects architecting and documenting the spec.  Six months has elapsed (of which maybe a month was actually doing stuff that positively contributed to the success of the delivery) and finally the developers start writing code.

What value did that six months deliver?  Requirements, design, business and estimates.  Yet we all know that the requirements will change, and with that the business case.  The estimates will be way out, but we’ll justify the process of estimation because they would have been right it the requirements hadn’t change during the build…

Knocking the process is easy.  What’s the alternative? Start with a burning desire to release something of value at the earliest responsible moment.  Get the business in the same room as the analysts and the architects and get them to articulate their vision.  Use personas and more importantly scenarios and customer journeys to drive out the business vision.  Ask the analyst to capture the business intents on index cards.  Lots of whiteboarding, visualisation and pictures to inform the thinking.  Don’t dwell on the detail, this is about capturing the intent of the system, what are the desired outcomes that it will deliver, how will it impact the lives of all the people who will touch it.  Next step is to prioritise these outcomes.  Collate these into the minimum set that would make a coherent and compelling product that you could go to market with.  For the business case make basic assumptions on the revenue that this feature set will deliver (or what costs it will save) and ask the architects and developers in the room to do some high level estimates.  The whole process should take no more than a week (you could get a first cut done in a couple of days) and there is your initial business case.  If we accept that estimates are little better than guesses and things will change anyway, if we have an initial realisable goal that we have demonstrated will deliver value, why not go straight into development.  By actually ‘doing’ you will minimise risks that you can only predict on paper, and value will be delivered so much quicker, indeed you should be able to have something to market, generating revenue in the same timescales that you otherwise spent planning and analysing.  And if you still want to do waterfall, you’ve got a smaller number of requirements to analyse and design for, again, delivering value sooner.

Someone should talk to the minister about agile

So another government IT project fails to deliver.  The National Offender Management Information System had been budgetted to cost £234m (total lifetime cost) and take four years to complete.  Three years in and the costs had spiralled, with a new lifetime project cost estimated at £690m.  The plug was pulled and a new three year project at the cost of £513m was commenced.  Poor project management was blamed, but I’d go further and blame the project approach as well.  The Minister responsible says why;

“As soon as the extent of the projected costs and delays to the project were recognised, we took immediate steps to halt the project and consider the most cost-effective way forward which effectively preserved the work done to date”

So let’s get this straight:

It took three years to recognise that a project to implement a single database had gone wrong

Contrast this to an agile project where progress, costs and risks are continuously monitored.  But what does the goverment do?  Continue with the same approach as before with some new project managers on the job.  And wait another three years before any value will be delivered.

How are you managing the change?

To the development team ‘change’ relates to scope and requirements within the project, but change runs far deeper than that.

A question that I am often asked is how do you manage business change on agile projects. Release regular and often is an often quoted mantra, but what does that mean to the business where rolling new software across the large, multi-site organisation? How do you manage the piecemeal introduction of new technology, features and functions to hundreds or thousands of people, many levels removed from the project across remote offices and geographical locations? How do you ensure the recipients of the new technology rapidly adopt it and accept the change, even when change is occurring every few months.

What are the financial and human performance implications of each new release in terms of training, productivity and morale? What is the overall burden on people in frequent change?

The reality is that it is not unusual for projects deemed successful by IT and the immediate business team to ultimately fail when released to the broader organisation. Effective change management can be even more important when an organisation adopts agile software delivery.

An analogy as an example. If I expect a screwdriver and you only give me a cross-headed screwdriver when I really want a flat head one I am going to be unhappy. The core team may have prioritised the cross-headed one first for good reason, a flat headed one maybe coming just round the corner, but if you don’t deliver to my expectations I am going to be unhappy. Worse, I am likely to become resistant to future change and less likely willingly cooperate with the uptake of future releases, even if they do start to deliver to my needs.

Keep it on the shelf
The first point is that regular and often does not necessarily mean release to production for the entire organisation or marketplace. Running a number of internal releases, keeping them on the shelf until a complete and marketable product is ready is a strategy often employed. Significant value can be accrued by getting tested and working software into a pre-production environment and held “on the shelf” awaiting a full release. This maybe a UAT environment where a limited number of stakeholders test the functionality in an ‘as-live’ environment. Or it maybe a beta release to a small, selected number of interested people (e.g. a ‘friendly user trail’). This can often pay dividends with usability issues and minor gripes being picked up and addressed before a major roll-out.

Communication

Let’s assume that the team wants to roll out the application early and often to the whole target population. Critical to the success of managing the business change is communication. It is important to manage expectations on a timely and appropriate manner. Explain what the upcoming release will do and more importantly what it will not do (and when it will do it). Keep all stakeholders informed of the project progress (setting up a project blog can be a cheap and easy way of letting interested people know of progress), yammer maybe another way of broadcasting updates and information. Having a release count-down can also prepare stakeholders for the change. The techniques can be googled, the important thing is to communicate and manage the expectations (and be ready for inbound questions and comment after go-live).

Adaptable user interface
It is not unusual for the core team to drive for as much functionality as possible in the first release, considering UI enhancements as ‘nice to haves’ and consigning them to later releases. This is a false economy. Consider the cost of training and lost productivity through a hard to use interface. Now multiply that across multiple releases that focus upon utility before usability. Delivering a first release that is self contained and compelling will go a long way to driving organisational buy-in of the new application and greater acceptance of future change. (Jeff Patton writes some great stuff on using story maps to explain what the system should do. Using these will help focus on complete and useful slices through the application rather than random features that are perceived to be of value but do not make a coherent product).

A new user interface, however well designed will inevitably take time to learn the first time it is used. The challenge is with each subsequent release to introduce funcitonality and interactions that leverages the users existing mental model of the application, building upon what has been already been learned. Starting with the end-state, wireframes that articulate the final application then trimming out features, feields and controls to represent each notional release can be a good way of ensuring a UI that will scale as new functionality is added.

Agile organisation
Ultimately the most successful way of introducing agile is to build a beta culture with everyone as agents of change across the whole organisaiton. More importantly change becomes a cycle of learning and continuous improvement. And here I’ll borrow this most excellent graphic from David Armano. David compares what he calls conventional and unconventional marketing but the parallel with software development is obvious. His iterative cycle is “plan-design-launch-measure” but that is not a million miles away from the lean philosophy of “plan-do-check-act”. And critical to the journey is the learning cycle between iterations.

Where’s the vision

Experience suggests that a project without a vision is like a rudderless ship. A clear vision from the start is essential to the success of a project. It is like the corporate mission statement. It is not the project objectives (objectives are generally SMART – you shouldn’t be looking to measure the vision), rather an articulation of how the end goal of the project will touch the lives of it’s ultimate recipients; the customer or the user. What the project will do for them (not the business, not for IT, but the customer, consumer or user).

The first step then is to get the vision agreed on. Luke Hohmann’s innovation games such as product in a box are a good way of distilling the vision. Next step is to keep it live and visible. Don’t just have it buried away in the project Wiki, but have it stuck on the walls where the team work. And then use it as a frame of reference when those difficult questions arise around scope and priorities.

Why is this important? (Via Leisa Reichelt), Peter Merholz shows how Google started out with a vision for their calendar.

The vision…

The google calendar vision

And what it meant for the product when it went to market…

Google didn’t start with a bunch of features of functionality (“Drop dead simple to get information into the calendar” – that’s hardly a requirement any BA would be proud of), but by having this vision, a statement of what the product would mean to the end user, and referrring back to it when scope or design decisions had to be made, they ensured that the end product delivered real quantifiable value.

1 of 2
12