Principles for Project Management and Process Improvement

Toyota’s 14 lean principles (detailed in Jim Liker's book The Toyota Way) have been culled out of long-term process improvement experiences and deep deployment initiatives in manufacturing scenarios. The software development processes at the observation level may be different, or at the abstract level may be same – debate is still on. However, keeping an open mind to observe and study the scenarios, situations and project organizations for providing software services, author has culled out seven interesting operational priniciples. These operational principles may not exactly match Toyata’s Lean principles, but are derived from successful and sometimes unsuccessful attempts in trying to apply them in the software world. The note describes these prinicples in brief and hope these 7 lenses will give a software value stream owner efficient tools to improve operational efficiency manifolds!

7 Principles that Stick

1. Plan your Project and Project your Plan
2. Collaboration is the key and it has two parts Cooperation and Elaboration
3. Identify and Exploit Concurrency where ever you can
4. Wait Times are Waste Times
5. Crisis Avoidance is an order of magnitude more profitable than Crisis Management
6. Best time to detect and respond to an error/defect/bug/mistake is while it is being created
7. Decisions made in the value stream and Handoffs in value stream are main flow decelerators

Principle 1: Plan your project and Project your Plan

First part of this principle is fairly straight forward. However, we typically plan projects with a linear way of work break down structures, etc. There is no framework to generate multiple project plan alternatives; rather it is found from author’s experience, typically there is only one project plan which gets refined, modified, developed, elaborated and at the end abandoned, as the reality moves so far away from it that there remains no point in following it. Further, there are no metrics to evaluate the project plan alternatives from the point of view of efficiency measures such as number of decision points, number of handoffs, time the work in progress will be waiting for the person to work or the person will be waiting for the work to come, workload balance in time and space, etc. Although this part of the principle is not done in a comprehensive manner, however there is a semblance of a project plan in most of the software projects.

It is really the second part of the principle, i.e., project your plan that is missed out completely. Once the plan is created and is expected to be followed, the complete plan needs to be projected to the team and all stake holders. Further the project plan should be a living document or artifact that keeps on reflecting the life of the project at a particular point in time. By doing this projection of the project plan, the anatomy and physiology of the software project is captured and is visible to all the stakeholders, thereby creating higher probability of finding crisis points much earlier. This helps in crisis avoidance which is the focus in Principle 5.

Principle 2: Collaboration is the key and it has two parts Cooperation and Elaboration

Software development projects and software maintenance projects are heavily people dependent. Further the persons involved have arguably higher education and IQ levels (at least they perceive) compared to other industries. If the team members are able to combine the skills in a synergistic manner, it can amplify benefits in multiple dimensions for the project. If the discussions or the ad-hoc, non-formal brainstorming sessions are carried out in open, synergistic manner, leveraging the creative tension, the teams can be much more effective. Cooperative elaboration is fundamental to carrying out efficient projects. This also requires involvement of maximum number of team members in maximum number of project activities. It is an important point to note and remember that the egos of software developers – because of the very nature of work they perform and the need to work in solitude – are higher than other classes of homo-sapiens. Making multiple team members to collaborate and elaborate in such a scenario is a major task for any project manager and as such needs much more self-organizing project teams than many managers are willing to allow.

Principle 3: Identify and Exploit Concurrency where ever you can

Concurrency is the parallel execution of multiple processes, multiple stages of a process, multiple tasks, or multiple activities which ultimately unite or unify to deliver final output. By identifying concurrent paths work can be executed in an efficient manner wherein the cycle time can be shortened considerably. Software development life cycle is typically a set of sequential phases which may get iterated due to multiple review points in the life cycle. Sequential process phases are generally followed as one phase may be dependent on the previous phase. However, by looking at the process activities and their interdependencies as early as possible, concurrent work paths can be identified and exploited so as to reduce the development time. A conscious, complete and clear focus on concurrency exploitation is absolutely essential for software process improvement.

Principle 4: Wait Times are Waste Times

Any type of wait in the process is sheer waste. Look at obvious wait times – we typically plan only for the people utilization, i.e., when people are waiting for work. However, the second type of wait – the hidden wait, is when the work which is partially completed waits for the next phase or person to work on it. These sort of wait which can be more dangerous as not only it is hidden but the focus is not on it at all. To create process flow, eliminating both types of wait times is essential. It is however criminal, when at the same time there are partial work items waiting to be worked upon and at the same time there are people who are waiting for the work. Identify all type of waits in the delivery processes and minimized or eliminate the wait times, as these are absolute waste.

Principle 5: Crisis Avoidance is an order of magnitude more profitable than Crisis Management

Crisis situations are those conditions in a project or process that have a high probability of turning into disaster in short time period. Disaster is defined as a situation of extreme loss. We usually find ourselves in crisis situations and would like to be designated as crisis managers. It is interesting to note that crisis managers are invariably in demand. Contrast them to a project manager whose projects do not have any crisis situations. These managers have smooth projects and hence these projects do not attain too much visibility. However, it is the practices and capabilities of these crisis avoiders that we need to imbibe in the organization rather than the crisis managers.

Principle 6: Best time to detect and respond to an error/defect/bug/mistake is while it is being created

This principle may come as a surprise as we are all so used to reviews, project post- mortems, etc, and we expect or rather let mistakes continue in the system during the development. It is surprising that despite knowing that the later we are in time from the moment of mistake creation, difficult it is not only to detect but also to rectify a mistake – we let the mistakes happen. This is in fond hope that reviews and observations later in the software development cycle will uncover them. But this is like the proverbial pigeon that on seeing the cat closes its eyes in the hope that as it is not seeing therefore cat is also not seeing it. Mistakes are part of human nature and will always be there. The point is that earlier the mistake identification happens less costly it is to fix it. Pair programming is a clear manifestation of this principle, where in, two programmers work at the same time on the same machine on the same program. Thereby not only developing together, but reviewing each others code at the earliest – in fact many times as it is being created.

Principle 7: Decisions points in the value stream and Handoffs in value stream are main flow decelerators

A value stream needs to flow. It is observed that more number of decision points make the flow lesser and lesser. Similarly more hand offs in the value stream indicates more inaccuracies, delays and reviews than in a value stream with less number of hands offs. In fact, we can define a Value Stream Choking Index (VSCI) as directly proportional to number of hand offs and number of decision points. Further, hands offs create a absolute hidden waste that is so intertwined with human psychology that it goes without notice. In a typical hand off between two persons, the giver is supposed to pass the artifacts and information in complete, comprehensive and unambiguous manner to the receiver. The receiver is supposed to get this information and artifacts and develop them further so that he can add more value to send it to customer ultimately. Typically in the hand offs there is tremendous loss because neither the receiver nor the giver puts effort to pass the information in unambiguous manner first time. This results in multiple meetings and rework and hence creating flow deceleration.

Kindly review and send your critical comments, thoughts and feedback to navneetbhushan@gmail.com.