Projects gone bad: guesses dressed as science

Been reading the current edition of E. F. Schumacher’s 1973 classic “Small Is Beautiful”.

In chapter 3, “Resources for Industry”, I’ve just found the provoking paragraph.

It is fashionable today to assume that any figures about the future are better than none. To produce figures about the unknown, the current method is to make a guess about something or other – called an “assumption” – and to derive an estimate from it by subtle calculation. The estimate is the presented as the result of scientific reasoning, something far superior to mere guesswork. This is a pernicious practice which can only lead to the most colossal planning errors, because it offers a bogus answer where, in fact, an entrepreneurial judgment is required.

This paragraph really hits the nail of the head, with regard to one reason why big IT projects fail. So much is unknown, then inferred and finally dressed up as the plan that can be done for a tight budget and time frame.

No one says the Emperor has no cloth. The plan says he is fully dressed.

This is an environmental book. A good book for a generalist read.

Well worth the read.


Gnoll110

Technorati tags:
schumacher small+is+beautiful project+management

To watch: Agile Toolkit Postcast

Agile 2007 was on last week, 13 to 17 August. Have a look at the site, some of the overheads and handouts can be downloaded.

With Agile 2007 being in Bob Payne’s home town. I’m sure he will have lots of great new podcasts for his Agile Toolkit podcast site soon.

Can’t wait!

I so hope Bob got to talk with Mary Poppendieck and/or Kenji Hiranabe about their Kaizen from Toyota [with MindMaps] session!

Refactoring Databases : Evolutionary Database Design by Scott Ambler & Pramod Sadalage looked interesting.

Lots of other cool sessions too


Gnoll110

Technorati tags:
agile lean+software agile+2007 agile+toolkit agile+podcast bob+payne

Good management, Bad management.

What to do.

The current situation.
This application software redevelopment area is divided into two halves. An accounting system and a 'document' processing system that handles incoming (claims etc) and outgoing (payment, notices etc) messages. Each of these is then divided into two halves. One group of teams converting 'service designs' (from a business area) into 'technical designs' of pseudo code. The second group of teams 'builds' the 'technical design' into modifications to a Commercial of the Shelf (COTS) product. The code is passed on to be compiled and tested.

The division between the analyst and programmer is said to be 'Chinese wall' that ensures quality.

In my book both are part of the software design process. Testing of function is the true validation of the design decisions (that both the analysts and programmers make).

The analysts browse the code base and database/massage/file schemas (no access to any usable dev or testing data) and are expected for get the 'technical designs' right first time. The programmers then code and unit test using some unit tests drawn up be the analyst.

This is madness, it breaks the short term (sub daily) feedback loop of an analyst/programmer doing coding and unit tests, and then feeding unexpected corner cases back into the code/unit test rig. It creates a paper/email feed back loop of days. Often the analyst is requested to modify a 'technical design' that he/she have not worked on for days or weeks.

I know one of the analysts. He told a few people there, that he thinks that the analyst and programmer roles should be merged. That the time resources freed up by the improved/shorter communications should be devoted to testing, particularly automated testing.

Now

Well where has been some movement. They are going to pilot a new team structure. The four person team, 2 analysts and 2 programmers, co-located even! One of the analysts will be the team leader too. Good management!

My friend is the second analyst. The team was setup on a Monday. The second analyst and two programmers found out about the new pilot team and their pending move to it, at about 11 am on the previous Friday. They were CCed in on the 'make it so' email.

My friend thinks it's a good idea, that it’s movement in the right direction at least. But he is mifted that he found out about it as a fata compli. Bad management!

Future

My friend thinks that they may want to keep the 'Chinese walls' in place. He wants to grow some 'grape vines' over it. He wants to learn the programmers tool set. He wants to get the programmers updating the 'technical designs' for more than just spelling mistakes.

Any extra ideas on how to improve this pilot team would be welcomed.


Gnoll110

Technorati tags:
agile+software lean+software analyst programmer software+management

Project Management as servant, not Master

Jason Yip posted this agility is not the point post to his blog.

• Deliver the highest possible quality and service to the customer
• Develop employee potential based upon mutual respect and cooperation
• Reduce cost through the elimination of waste in any given process
• Build a flexible production site that can respond to changes in the market

I've started to work through Agile Web Development with Rails. In Chapter One, there is this section titled Rails Is Agile (1.1).

Let’s look at the values expressed in the Agile Manifesto as a set of four preferences. Agile development favours the following.

• Individual and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Last week we had a talk at work about Project Management (PM), went for about an hour.

At the end I expressed my opinion that Project Management trended to make an organization too lean. Lean in another sense of the work, as in over worked!.

This weakens the organization in three ways.

• Insufficient resources to respond to the unexpected, particularly human resources.
• Lack of maintenance of corporate assets, like the code base.
• Lack of deep infrastructure planning. When I say deep, I mean the shared resources used by most operational activities, including human resources.

Noone actively disagreed with me, including the three Project Managers present.

Been thinking about it more. Thinking triggered by this Seth Godin post & Jason’s post above.

The trouble with PM is when the organization develops a minimum cost/big bang approach to doing things. Be as low cost as possible, gets bodies in to do a job, gets rid of bodies at the end. The public sector is really prown to this!

One issue is that the milestone become the end all. How do you avoid this, it’s natural, the money has got to be tied to something.

PM ends up big on following Process, big on Doco, big on the Plan and big on Contract Negotiation (due to scope creep), putting it at odds with the agile preferences! These are all forms of waste in Lean terms!

Now I’m all in favour of project management (all lower case).

To steal Rowan Bunning’s tag line

"In preparing for battle I have always found that plans are useless,
but planning is indispensable." - Dwight D. Eisenhower

pm makes you think, it’s acting on the useless plans that is a waste.

Where to now?

Well the opposite of minimum cost/big bang management would be maximum effectiveness/steady state management.

What would that look like?

Maximum effectiveness means you’re not measuring costs. You are measuring outcome to expenditure ratios. Further more time and none monetary factors don’t go straight out the front door, as they do when what is being measured, is measured in dollars

Steady state implies that you keep a large core of personnel who maintain existing activities, do projects as needed and are there for the unexpected. You supplement them with specialists and contractor as they’re needed.

Another way of looking at this, is to treat employee as profit centres. That mean the organization tries to develop its employee full potential.


Gnoll110

Technorati tags:
project+management lean agile agile+manifesto