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.
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?
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
|
a. Project level
b. Business level*
|
* 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
|
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.)
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:
- Defining Fitness for Purpose, by David J Anderson
- The Project Management Principles That (Almost) Nobody Teaches
- Measure and Manage Flow in Practice by Zsolt Fabok