Kipling's Advice for Project Managers

I keep six honest serving men
(They taught me all I knew);
Their names are What, and Why and When;
and How and Where and Who.

– Rudyard Kipling (1865-1936).

Any plan must

1. Set out the objective - the "What". 
2. Explain the reason - the "Why".  
3. Specify the steps that are to be executed - the "How".
4. Specify time sequence for execution - the "When".
5. Specify the place, or the objects, where, or on which, the steps are to be completed - the "Where".
6. Specify the persons responsible for the execution of the steps- the "Who".

Come to think of it, source code documentation too, with the possible exception of #6, should have the same information.

Commitment- Lessons from Indo-Pak (1971) & India-China (1962)

I recently read Arjun Subramaniam book "INDIA's WARS". On pg342, he describes how, in April 1971, Indira Gandhi was a "trifle disappointed" when Gen Manekshaw, the Chief of Army Staff, did not agree to launching an attack immediately on what was then East Pakistan. Manekshaw asked till December. Indira Gandhi deferred to Sam Bahadur.

Manekshaw had not pulled the date out of his hat (not withstanding it was a brass one :-). It was a commitment made after due study by field commanders, and their staff; the people who would be tasked to meet the commitment. Manekshaw listened to their professionally argued case.

If the Indira Gandhi and Manekshaw did not behave as they did, 1971 would, most likely, have been a disaster.

Compare that to 1962. Nehru had not listened to his Generals; had not listened for many years. The army hierarchy was disrupted, thanks to Nehru's Defence Minister. The army lacked the capability for which it was tasked. Yet shortly before hostilities broke out, while boarding a flight to Ceylon (now Sri Lanka) he told the press, that  he had asked the Army to throw throw the Chinese out. He had obviously not asked - or asked, and not listened to - the commanders who would have to do the job. 1962 still rankles.

The two episodes from modern Indian history demonstrate how to - and how not to - make a commitment. Commitment

• Cannot be dictated. It is bottom-up.
• Needs a trained team. Some factors.
• Building a trained team takes time. In the case of Manekshaw and his commanders, decades. 
• Training means formal accumulation - and dissemination - of lessons learnt from actual experience. The armed forces have many mechanisms  for this. 
• Teams must be sustainable. People leave. New members have to be inducted.
• Teams need Leadership. Management is needed. Leadership is essential.
• Needs organizational culture; a culture where reasoned dissent is encouraged; not penalized. And "Chamcha-giri" bears no fruit.

Software schedules too need commitment. Organizations that have software projects should adopt the culture of 1971. Sadly, many software companies operate with a 1962 culture.

Innovation: Established Organizations & Startups - Learning Process

In my earlier post I mentioned that Govindarajan & Trimble describe a rigorous learning process.

The effect of a rigorous learning process is that estimates become progressively more accurate over time. They illustrate it with a diagram. The diagram is precisely what softwarewallahs call "The Estimation Funnel"! (See my post on Estimation).

Estimates are based on hypotheses about cause and effect; they are of the form if < action.> then &lt;result>. Hypotheses, as in the scientific method, must be tested by experimentation. Evaluation of results must be free of biases (the authors describe these biases). Adhering to the sceintific method is what makes the learning process rigorous.

The genesis of all startups too are a set of hypotheses. These concern pain points, market size, value provided, revenue streams, costs, ... All of that goes into the business plan. The business plan is a set of hypotheses about business reality. It is not business reality. The rigorous learning method is required to evolve the business plan to conform more closely to reality.

The authors provide a simple graphical tool for recording the hypotheses. They call it a "hypothesis of record". They illustrate it with an example of how Analog Devices actually put it to use.

Further, the acts of making the business/innovation plan and rigorous learning cover, in my opinion, the first three steps of the Shewhart PDCA cycle. Not surprising, as continuous quality improvement too is based on hypotheses.

Estimation

Interesting set of slides on Estimation.

Slide 2: Is the estimation "funnel"

Slide 11: acmet's tools BU fell in the Nominal category.

Slide 14: For 10K lines (I do not know how these are defined - whether they include data definitions, unit tests, documentation, ...) 10 calendar months and 48 (say 50) staff-months. That is 10 lines/day ((10K/50 staff-months)/20 days/staff-month). That is somewhere near the figure that we got. Also, no mention is made of the expected residual defects.

I have a thumb rule: The number of residual defects per 1K XTSLN equals the effective XTSLN/staff-day over the elapsed time. At 10 XTSLN I would expect about 10 defects/1K XTSLN. Of course to get 0 defects/1KXTSLN we would be coding at an effective rate of 0 XTSLN/staff-day. That is not as odd as it may sound. To reduce to zero defects one would require infinite time.

(Note: XTSLN is a Lines of Code metric defined and measured by the QA C tool)

Slide 18: This is my favourite. It illustrates the estimation funnel. Note
the relative error column. There is not even 1 negative entry! For a 5 year
project the estimate becomes accurate 3 months prior to ship.

Slide 22: Note the last bullet.

Slide 23: **** Worth remembering *****

Slide 26: These are all the recovery techniques.
Note: Praying is *** not *** a recovery technique.

CWG: Time To Do The Hansei

The Commonwealth Games by all accounts went off well. That it was headed for a disaster will soon be forgotten. If we do get the 2020 Olympics there is every likelihood that we will again prepare for it in the same manner.

A large complex project, involving multiple government agencies, with no option of slippage requires a highly skilled and motivated management team. And since the national image is involved, the team must have access to, and the whole-hearted support of, the highest rungs of the political leadership. Suitable talent should be shortlisted. The UID project, headed by Nandan Nilekani, brought in with the status of a Minister of State in the Union cabinet, should be the model.

Based on the current experience, we need to create a project plan - complete wih check lists (e.g. signs near building housing the ozzie team saying,"Beware of Falling Refrigerators:-). The project plan must be periodically reviewed and updated since financial conditions, technology, security environment, facilty benchmarks, vendors, ,, all will change. The sports ministry should do this, if we are serious about conducting the 2020 Olympics.

Holding enquiries into alleged siphoning of funds, punishing the guilty, assuming any are found, is all very well, but it will not reduce the chances a repetition.

For that we need to do the Hansei.

Lessons from the Commonwealth Games: Deadlines?

The media has been reporting one Commonwealth Games deadline after another being missed.

What should happen when an activity misses its deadline? Should not the activity be declared dead? The outcome of the activity ceases to be relevant after the deadline. Why else call it a deadline?

The fact is these are not even estimated dates of completion. These are just ordered from on high: "Thou shalt complete this task by dddmmyyyy, or thou art dead". It may induce fear. It certainly does not get buy in. People get very adept at passing the buck. Forget about being dead, no one is even held responsible.

Does it happen in software companies? I am sure it does. At one time it used to happen at acmet's Tools BU.

Lessons
Remember, we deal with estimates. Not deadlines.
Estimates must be made by the people who have to do the execution.
Estimate, and re-estimate, on the basis of performance till date.
Do not hide the bad news.
Learn (Do the Hansei). It is better than fixing responsibility.

Lessons from the Commonwealth Games: Media as QA

It struck me that the role played by the media in respect of the Commonwealth Games (CWG) is very akin to that of QA.

In software companies QA is part of the organization. It does have visibility into the process being followed. But, as often happens, management pays it lips service while concentrating on somehow "staging the games". When the schedule is under threat QA goes out the window. Being a part of the organization, it would be an extremely dedicated QA which would inform the customer.

On the other hand the media, though a part of the establishment, in India, is independent. Being independent they do not have official visibility into CWG organizing committe's processes. But they have their sources of information. However, no sources are needed when the result of the process is there for all to see. The media just have to report it. Where the result is not plainly visible, as in the case of the games village, it will be seen by the customer - the participating teams.

Did the CWG organizing committee have an internal watch dog? Did they listen when the watch dog barked? They could have had a good external QA if they had allowed the media visibilty into their process. By not having an effective QA the organizing committee did not get the bad news early.

Lesson for Software Companies:
Allow QA full visbility into the process. Get the bad news early. Do not shoot the bearer of bad news. Do not indulge in self-delusion.

Project Roadmap or Project Plan?

Quite frequently I see the two terms used interchangeably. I think there is a difference.

A road map is not a plan. To use a software term: A road map is just a data structure.

To get from city A to city B by road, one consults a map to decide on means of transportation; the route to take; contingency routes; what are the other cities on the way; road conditions; refuelling stops; weather conditions; ... That does not make it a travel plan. It is when we plug in estimates of dates and estimates of travel time and estimates of stop times, and decide on preparatory measures that it becomes a travel plan.

Different travellers can have the same road map for getting from city A to city B. Yet they may have different travel plans.

A Project Roadmap just has a set of paths to desired project outcomes. It is estimates of time, and allocation of resources, that create a Project Plan.