Let's accelerate your business agility I Faster organisation I Blogs

Delivering IT projects, on time, on value, on budget

[fa icon="calendar'] 2017-05-01 09:30 / by Nader Talai posted in Selected Blogs, Growing Agility

[fa icon="comment"] 0 Comments

IT Projects fail to deliver their goals! 

The success rate does not increase, but let’s keep going the same way.

 
Single stage funding, project teams and the thinking that the reason for previous failures is the lack of planning and process control have led us to more detailed planning, more and more detailed business cases that focus on breaking down the delivery timescales and more prescriptive methods. We have been pursuing this deterministic approach to achieve perfection without success.
 

Build it and they will come.

Our project approach is based on thinking that customers will come to us; we are thinking inside out, as opposed to outside in.
 
We need to put the customer and user needs at the centre of everything we do and build for the customer needs. When we have the user needs at the centre we start to have a different approach. Instead of pursuing certainty we start to look for a different kind of certainty, knowing how to invalidate our hypothesis about user need? 
 
Our ability to discover customer needs quickly and cheaply coupled with the ability to deliver against our discovery is the key differentiator.  

Faster Organisation 

Lean and agile ways of working enable organisations to learn faster and deliver. This alternative significantly increases the chances of success by adopting an evolutionary approach that is designed to navigate uncertainty, learning faster and adapting to new information.
 
Elements of lean and agile delivery
  • Hypothesis-driven
  • Pull-driven
  • Feedback
  • Visualise
  • Collaboration
  • Teams
  • Synchronisation & Coordination

 

I want to book my free faster business consultation

 

Hypothesis-driven

We create certainty where one does not exist. We do this all the time and unconsciously, our approach to funding projects is no exception. We want certainty that our investment will deliver the results that we desire, so a detailed business case and project plan that creates the certainty we desire is required. The business case and project plan go through a series of elaborations until the project is approved or occasionally, rejected by the investment board. The problem is that we have created an illusion of certainty where our domain is uncertain.  

Navigating uncertainty

Step 1

How do we measure success?

  • Define evidence of success up front
  • Define the buyer persona
  • Define the hypothesis

We can now have a well-formed hypothesis

We have a hypothesis that delivering these features for these buyer personas addresses these needs and will deliver these outcomes. We know we have been successful when we have the evidence.

 

Define the measures first.

Step 2

Fund for the value of the outcome and the discovery needed to invalidate the hypothesis.

Fund the discovery.

Step 3

Learning, what are the experiments we need to invalidate our hypothesis with minimal investment?

Define the first experiment.

Step 4 

Carry out the first experiment and measure the results.

Use what you've learnt to define your next experiment.

Step 5 (when the hypothesis is proven)

If we invalidate the hypothesis, that is great because we have now saved a lot of time and money. The majority of the hypothesis will be invalidated but the learning we gain from these will lead us to a better hypothesis and outcomes.

Start the build only when we have a valid hypothesis.

We know the measures.

Fund for the outcome

Measure, build iteratively, learn 

 
PULL-DRIVEN
Our standard approach is push-based where we believe the sooner we start the sooner we finish and the more we start the more we finish which leads to slow and late delivery as the result of multi-tasking and diluted focus. 
 
Pull-driven, work is pulled in when we have availability and capacity to do it, this is because we value finishing over starting. 
 
How can you I start my journey to achieving a pull-driven work?
Start by measuring your delivery rate as a cumulative flow and add the rate at which you start new projects, see the chart below.
  1. If your start rate exceeds your delivery rate, stop starting new work.
  2. Only start new work after you deliver. 
  3. Measure work item ageing.
 
This approach of limiting the work in progress to a constant number, CONWIP, is one way of limited WIP. The cumulative flow for the above once we implement CONWIP looks like below.
 
 
Read More [fa icon="long-arrow-right"]

What's really slowing you down, and how to visualise the value flow?

[fa icon="calendar'] 2017-01-06 15:05 / by Nader Talai posted in Selected Blogs, kanban, Customers, value stream

[fa icon="comment"] 0 Comments

Are you managing your people or managing the work?

Read More [fa icon="long-arrow-right"]

What does it take to have a successful sprint planning?

[fa icon="calendar'] 2014-12-03 20:51 / by Nader Talai posted in Selected Blogs

[fa icon="comment"] 0 Comments

Readiness - that's it!

What it takes to be ready depends on your context

How long has the team been working together?

 Book Your Free Consultation   

How

Read More [fa icon="long-arrow-right"]

Now we are agile we don't need to ...

[fa icon="calendar'] 2014-11-16 10:34 / by Nader Talai posted in Selected Blogs

[fa icon="comment"] 0 Comments

Stop the agile prefix

With agile ways of working becoming more and more popular there is a tendency for orgnisations who start their agile journey to prefix everything they do with agile.

Read More [fa icon="long-arrow-right"]