March 26, 2009

Where has all the money gone? – you wouldn’t believe it

Filed under: Systems, Uncategorized, feasibility study, project management — Tags: cost cutting, implementation methodology, process, project management, red tape, systems methodology — admin @ 2:12 pm

Part one – why?

Previous installments:
IT investment for the small businessman and novice
Why the SMB/SME holds all the aces when it comes to IT
In our last instalment we talked about the advantage an SME/SMB has over it’s bigger rivals when it comes to implementing technology, especially around the aspects of communication, business change and lack of red tape.
Don’t let this reference to red tape fool you. It is mission critical to understand the difference between vital process and red tape and it’s not always immediately obvious.
The key to cost cutting in any area is knowing what to cut. The word we are after is waste, but even that can be misleading. In the world of Lean everything outside of the critical value adding moment is deemed to be waste, but nobody imagines that you can eliminate most of it let alone all.
The best approach is to look at where the money goes in a typical systems implementation.
Let’s take ACME cash registers.
They have a turnover of 200 million and they have countless systems handling different aspects of their relationship with customers. Nobody in the organisation has the full picture at any time bout any customer.
Sales people call with an Upsell proposition within an hour of the customer complaining bitterly to support.

Customer enquiries get written on cards and handed to salespeople who then lose a percentage or forget to mark them up so 14% of leads are never followed through. (any of this sound familiar)
The last time they tried a mass emailing they only had email addresses for 34% and two thirds of those were returned undelivered. This resulted in their IP address being registered as a spam house and for three months their emails were being destroyed by a robot and never arriving.

Ok this is just the tip of the iceberg, but you get the picture. The new VP of sales has read the riot act and reluctantly he has been promised that they will try and find some budget to help out. Where do we go now?
In our next contribution we will provide an insight into how not to approach it and the we will move on to look at a simple model for getting this job done.
Requirement gathering the first big mistake

About the author

Comments (0)

June 16, 2008

Agile development is the opposite of Fagan type process inspection, is this a phenomenon or another short lived fad

Filed under: Systems — Tags: agile, Business analyst, Fagan, process, quality, six sigma, software engineering — admin @ 10:05 pm

Programming is the discipline of talking pure logic to a machine that will unfortunately take everything you say literally and act upon it.
Process, is continuum of actions or mini processes that have inputs and outputs is repeatable.
The programme is a process and the programming too is a process. It is therefore not surprising that many old school programmers simply can’t accept the principals that make agile development successful. Are they right?
The Fagan method of code review is a milestone in the thinking that developed around software engineering in the seventies. Invented by no less an authority than IBM, the same organisation that taught me agile fifteen years later, the Fagan method set out by code review and manufacturing strength measurement, to eliminate errors and produce perfect code.
This was not Six Sigma, but a measurement of sufficient opportunities to eliminate reworks at the earliest stage. IBM claimed substantial improvement in case studies published. The impact on software success rates was not however significant and I, at least, am not shocked by this revelation.

Here’s my take:
Software is built by trial and error, simple as that. Anyone who doesn’t know that has never written code and needless to see , few people who have written code ever get involved with lofty ideas like quality improvement.
1. Treating something like software development as a continuous process that can be accurately measured and improved is a theory that has some purpose but is limited in scope.
2. The problem with software is not and has never been the quality of code.
3. The definition of quality is invariably wildly inaccurate when it comes to software products.
Measurement and process improvement
I have had mixed successes in the past with Fagan like measurement of exit criteria form tasks or products and form analysing the scope and quantity of bugs by programmer, designer, functional area and other criteria. Luckily I was doing this in an organisation where i was surrounded by professional researchers an statisticians and despite my best efforts to gain and follow their advice, not a single test I could devise was able to satisfy their strict criteria for reliable measurement.

The things that did pay dividends was creating over time a culture of following strict guidelines and strategies that reduce the risk both at a design, documentation, communication and process level.
The real problem with software
Any time you analyse the causes of failure in software projects, the causes are found in a just a few places:
1. The commonest cause of failure is that the system delivered does not meet the needs or expectations of the users or stakeholders. Bad requirements, bad communication, bad UAT, took so long that the needs had changed, etc , etc
2. The business case was built on flawed assumptions and it should never have been completed, but pulling the plug is seen as failure while a poorly performing, or even stifling system is not.
3. Too little time was spent on the core needs and too much on the flora and fauna around the edges
The definition of quality
I’m not going to quote anyone , but t bravely state that the proof of the pudding is in the eating.
This system must satisfy users by helping them to perform to the expected level or exceed it and that includes keeping them motivated or better still re-motivated. It must also satisfy stakeholders that it is delivering an acceptable return on investment
Not a definition I know, but definitions are not all they are cracked up to be

What’s the verdict then
Well my verdict is that we should use process intelligently whether at a detailed level or a framework level and bearing in mind the power of a motivated workforce, but should not try to drive a square peg into a round hole in terms of ordering something that is about intense and accurate human interaction between professions that share little understanding of each others worlds. What delivers the goods or gets the job done is thing that delivers quality.

At IBM, not so long after the Fagan era, I learned to my astonishment that, in direct contradiction of his earlier paper, the cheapest way t fix bugs was not to fix them until you had to. This was measured very simply on the basis of whether the bug was preventing testing form continuing. If not, the developer could decide to ignore it and usually did. Once a week we all got round a table with a huge projector screen and we analysed the bugs together, drawing simple dependency links as we predicted the relationships between them. Every programmer knows how one bug causes several and sometimes the one causing them is not manifesting itself in any other way.
A group of switched on brains after the first coffee of the day could general choose one or two bugs each to work on which resulted in most of the remainder disappearing and not returning.
If these bugs had been tracked down doggedly by tired individual programmers we would have lost cumulative weeks chasing shadows and ignoring the power of collective minds over large area of complexity.

My belief is that well managed agile approaches to software improve communication immeasurably and eliminate the chance of a system not being what was expected. I think this is already applied to other processes from having a suit made to furnishing your home.
I also believe that quality in delivery is as much about motivation and peer review and recognition as it is about process, testing, logging and measuring. Real quality is built in and can’t be applied afterwards. In my view, well managed agile creates a vibrant team environment where programmers have direct contact with end users and stakeholders and receive regular feedback and recognition.

How quality should be measured
Quality is measured very simply by how the software performs for the user and delivers for the stakeholder and the two go hand in hand. The quality controller is mostly the user with input from the stakeholder and a technical reviewer. Perfect software with nill defects is not only unnecessary, it is not wanted in a world changing so fast that it will most likely be discarded in a short period of time. Fit for purpose is the ultimate measure, once purpose has been agreed.