Lean Kanban Analytics: Pragmatic Project Management

Dibujo Mindmap

I started working as software development project manager in 1996. We were a team of 5 people, young and motivated, developing a facility management system for a bank.
Just to give you an idea of that time, we had internet access on one computer only, so we were checking the team’s email (not the individual ones) twice o three times a day. The mobile phones were like the one you see on the picture bellow, i.e. no sms, no WhatsApp, nothing of this type.

Computer_Handy_1996

That was the only project we were working on, i.e. there was no resource sharing among projects and no influence from other development undertakings.

Do you remember that time too? :-)

As a project manager I was responsible for planning, tracking and reporting project work. The customer expected high quality product, however was patient enough to work with us on the requirements and give us the necessary time to implement and test them.

Piece of cake, isn’t it?

Nevertheless, before delivery we still had to work long hour to make sure that everything worked well. That is to say, estimates did not meet the actual values.

Estimates and actuals are different values of the same parameter.
Do not force (manipulate) actuals to fir exactly the estimates.

Survival and sustainability require pragmatism

Less than 20 years later few project managers, if any, can imagine leading a single project, with a team fully dedicated to it, no interactions with other developments, almost no interruptions, some manageable requirement changes, and mainly technology-related problems.

The interesting thing is that the complexity of the project management methods has increased in parallel to the increasing complexity of the software development, while the time for getting the right decisions is getting shorter and customer expectations higher.

I checked my notes from the last several years and what project managers share about their work is the following:

  • It is difficult to manage the variety of factors that influence a project: clarity of requirements, technology stability, level of knowledge and skills of the team members, risks, dependencies on other projects, etc.
  • The more sophisticated the estimation method, the more effort (and time) it takes to make a good plan, which anyway has a very short life until it changes again
  • Estimating, planning, monitoring and re-planning is a big administrative load, difficult to sell to customers, and therefore to sustain
  • There is lots of pressure to give estimates quickly and afterwards meet them.
  • Difficult project coordination

In such a situation shouldn’t we revise the well-established project management practices and look for more pragmatic ones?

Applying complex methods to complex situations
makes them even more complex.

Lean Kanban approach to project management

So, what is the project management purpose? – To make sure that the project fits the criteria of its stakeholders (customer and organization). Right?

Here you have them listed:

Project fitness perspectives

Customer

  • Deliver quickly (time)
  • Deliver on time (predictability)
  • Competitive price
  • Quality (get the right product / service)

 

 

 

a. Project level

  • Estimate (time, cost)
  • Predictability
  • Quality
  • Projects coordination

b. Business level*

  • Sustainability
  • Service orientation
  • Survivability

* See David J Anderson’s talk and post on Kanban’s 3 Agendas.

Then project fitness dimensions and the corresponding analytics tools can be summarised as follows:

Project Fitness Dimensions

Delivery time

Cost

  • Cost of value-adding, transactional and coordination activities
  • Cost of waste (bug fixing, rework, waiting, etc.)
  • Discarded requirements / stories
  • Efficiency

 

 

Predictability

Quality

Business

Click on the links to see how each one of the tools is used and what valuable information it brings to your project.

If you have a look at the tools you need to check your project fitness with respect to any criteria, customer or organization’s one, you will notice that you only need enough and, of course, good real data. (With respect to data, we always have to remember that Garbage in – Garbage out.)

The power of real data, not speculative estimates, gives you confidence
in your commitments and a quiet sleep because
it lowers the risks of not fulfilling your promises.

 

In addition, you save all the effort for inventing and updating a formal estimation method and trying to adjust it to the unique characteristics of each project.

For CMMI companies:

  • Delivery time (Lead time) is mainly collected in service-oriented work (for the needs of the SLA management). However, this is a valuable data for software development projects as well.
  • In software development projects usually the effort for a task completion is registered, but not the Lead time.
    Effort and duration is not the same thing.
    Knowing the real Lead time distribution for work types or classes of services helps getting more realistic planning.
  • Knowing the Throughput allows (through the Little’s law) giving a quick and reliable estimate of the Lead time needed to implement a set of stories / requirements.
  • Work visualization by means of Kanban board greatly facilitates project coordination.
  • The CFD is perhaps the best real-time indicator of work pace and risks.

You could also like to see:

Comments are closed.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad