Definition of the day - Regime Switch

A Regime Switch is a situation where the attributes of a system change to the extent that, to an observer, the system becomes unrecognizable from it's original state.

Quote of the day - Leadership

"If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea"

- Antoine de Saint-Exupéry

The Art and Science of reliable software estimation

The relationship between I.T. and the enterprise is a difficult one. Currently, internal I.T. is in a transition phase from internal service provider to manager of I.T. services either delivered by suppliers or as commodities, usually online.

To put this in perspective, let us consider the common trend towards outsourcing throughout the enterprise. There was a point in the past where pretty much every service that a large business required was done in-house. Facilities management departments would retain large teams of skilled staff. Over time this has changed to the management of external suppliers by a small team that is more about procurement and project management than about understanding in-depth, the skills necessary to deliver those services.

This has been a gradual but inexorable process operating over the last thirty years or so, during which pretty much all of these services have been either outsourced or commoditised. This process, with which I was heavily involved in during the early part of my career, was also largely painless.

It is a cause of frustration and confusion at senior level, for managers that have been through this with other parts of the business, that the process around the outsourcing and commoditisation of I.T. is proving so difficult. The reason for this is the critical nature of the processes over which I.T. presides. There is nothing more important to a business than its business processes.

At the heart of the pain in the relationship between I.T. and the enterprise is the perception that I.T. doesn't deliver on its promises. If we look at the number of software projects that fail to deliver it is quite difficult to disagree with the validity of that perception.   http://spectrum.ieee.org/computing/software/why-software-fails

Inaccurate software estimation has fundamentally undermined the relationship between I.T. and the business and once trust has been lost there is a long road to recover it.

Why do software requirements, seemingly inevitably, overrun on the initial estimates?

There are two main reasons, one is technical and related to complex systems and the other is human.

We don't know what we don't know.
In any large estimation process there are a number of imponderables which can have a significant impact once dependencies between the various components of the project have been played out, but deep at the heart of failed software projects are those grim moments that consist of the dawning realisation that some piece of software, technology or process will simply not do its job or behave as expected.

During project initiation, questions are asked relating to the third-party and legacy components of the project and the answers that are received guide the project team in its architectural and estimation decisions.

When we ask questions of suppliers, owners of legacy code or the third-parties with whom we are to integrate, our level of assumption about likely outcomes is necessarily higher than with our own code. The level of complexity is usually so great that it is impossible to know about all of these components and accurately identify the risks related to coding against them. Drafting in expertise is not an answer as, should one retain an Expert, it is not unusual for the said Expert to respond to direct questions in an enigmatic manner leaving the questioner no wiser than before the question was asked. There are numerous good reasons for this; from a failure of the Expert to understand the business requirements to an understandable reluctance to commit to decisions about a system that is in design and of course, potentially a desire to be retained for a longer period.

In summary, the domain of expertise of the architect is unlikely to span all of the technologies involved in sufficient detail that he or she will be able to assess all of the risks fully. This will inevitably result in the existence of the unknown unknowns which will then be encountered during the project.

This doesn't just apply to the architects but also to the developers as they need to code on a day to day basis against the components, interfaces or legacy systems, the behaviour of which is obscure to them. Hence a two week task is as likely to overrun as a two year project.

The need to please
Most people spend most of their time in a process of gaining approval. This is how humanity operates. In a business, staff seek approval from each other and from their managers, managers seek approval from their managers. Everyone seeks approval from the CEO who is bound to the investor's wishes and so on ad infinitum. There are also other drivers for the underestimation syndrome such as insecurity contributing to a feeling that we might take longer than others.

What this means in practice is that if you ask someone in a competitive environment how long a task will take they are most likely to underestimate and choose the least possible time that they think could be taken to complete.

The Science
Any process that delivers accurate estimation must take into account the above two issues; optimistic estimates and the unknown unknowns. That would seem a pretty tall order on the face of it as these are clearly unpredictable but there is a methodology that will improve the accuracy of estimates which is called Evidence Based Scheduling.

Evidence based scheduling
The only way we can possibly capture the effects of skewed estimates and unknown unknowns is historically. There is simply no way of factoring in influences like these as we proceed. Evidence based scheduling operates by taking past estimates and comparing the estimated time with the actual time taken. This gives us a ratio between the two which, free from other influences, will result in a value which we can use to multiply an estimate in future to derive a more accurate estimate. In all, for the average team, this transition will take three or four months to deliver a consistent estimation process.

The prerequisites for evidence based scheduling are;
• A change management system that allows estimates and actual times to be captured for each task.
• A business process that ensures the estimates and actuals are entered for each task.
• A way of excluding exceptions to the process which includes but is not limited to; pilots, documentation tasks, prototypes, completion of functional specs and so-on.


How it feels working in an Evidence Based Scheduling process

From the perspective of the business user;
• Either brief a business analyst or prepare the requirements using a use case template.
• Present the requirements for estimation.
• Accept or reject the estimate.
• If unacceptable either review the requirements or move on.
• If acceptable, accept the schedule.
• If the schedule is unacceptable ask for the task to be re-prioritised.
• If the schedule is acceptable receive delivery of the requirements on the due date.


From the perspective of development;
• Receive requirements for estimation.
• If the requirements are unclear, request clarification or a graphic.
• If the requirements are clear and a pilot or prototype needs to be done, estimate the time necessary to perform the pilot or prototype. (This is known as a spike).
• If spike time is acceptable, complete spike.
• Deliver estimate.
• If acceptable, implement the changes as per the priorities on the schedule and deliver to Q.A.


The Art
Convincing development that evidence based scheduling is in their interests is not usually a challenge once the benefits of reliable estimates and consistent requirements have been articulated, though it is never possible to assume that just because something makes sense that it will be easily accepted.

A process must be in place within the business to support evidence based scheduling which is why it has failed to become a universally accepted practice. The supporting process needs to deliver consistent and manageable requirements. Variations in the quality of the requirements can undo any stability in the estimation process. Reliable estimates rely on reliable requirements.

To be consistent and manageable, requirements must be described in a consistent format, ideally a use case, and also with adequate detail. The proof of this is that there are no holes in the requirements and that they are comprehensible

To be manageable a requirement should not consist of any individual task that takes longer than four days to code. Longer requirements must be revised into a collection of tasks of under four days and prioritised. The reason for this is that the longer the task the more chance that some detail of the requirements has not been considered and there is a hole that will extend the time taken. Any large task can be split into smaller tasks. If that is impossible it can only be because the level of detail is unavailable and so it will not been thought through. In this case, the author of the requirements must go back to the drawing board.

Implementing this entire process is difficult because it describes the relationship between the business and development and that relationship usually consists of something other than finely grained, consistently presented requirements. Change will usually be necessary and as we all know, instituting change is the difficult part.

If I'm in marketing, my job is to devise and implement sales strategies. I may have a requirement which I need to be developed. I want to get this done but I don't want involvement in the technical details to limit my ability to do the thing for which I am employed, salaried and possibly also commissioned. If I am expected to spend hours in meetings discussing the nuts and bolts of what I need from development then I can't get on with my job which will frustrate me and possibly limit my effectiveness thereby impacting the business.

The results of me not contributing may however, play havoc with the schedule. What I must do in order to ensure that I get what I want when I need it from development, is to commit to the requirements process to ensure that an accurate estimate can be produced. In other words I need to buy in. I need to have the case described for evidence based scheduling and I need to be able to see how important it is for me, for development and the company that I engage in order to get what I need when I need it. I then need encouragement to continue and improve how I articulate my needs.

Delivering evidence based scheduling is a tall order that requires buy-in from the business users, development and senior management. It needs a champion of sufficient commitment, patience and gravitas to carry all of those parties through the process when things become difficult and who can enable the enterprise to realise the benefits of a new relationship built on a foundation of reliability and mutual trust.

Quote of the Week

"Money never bought anyone any friends but you get a better class of enemy."
- Spike Milligan

Profitability for Independent Software Vendors in the post-recession economy

There is a vision of ISVs that consists of a tiny team of uber-Geeks insanely typing in a room with a soda machine. Code streams up their screens as they create visions of the future with their brains, imaginations and fingertips.

Though such places and people do exist, I have seen them, the factors that lead to sustainable profitability for ISVs since the Great Recession are far more mundane.

Right now, the software industry is going into it's phase of maturity. Success for an ISV relies on it adapting to the new environment and migrating to a sustainable and mature enterprise model.

To the uninitiated, this is NOT just about cutting costs by moving development and services offshore.

In practice, a sustainable Enterprise model is about three things;
1. Doing whatever is done wherever and however it can most efficiently be done - competitive necessity.
2. Cutting the costs of production - financial necessity.
3. Purchasing Services as a commodity - provides control and flexibility.

As an investor in technology, I would want to see the evidence of these process prior to making a technology investment.

Let us confront the issue of job migration as a method of reducing costs.

The simplistic, and wrong, approach is the concept of taking a team and moving it and it's tasks offshore. Fundamental to the success of this process is the belief that individuals in the offshore destination perform the tasks of the onshore workers as efficiently so that all that is needed is to hire the offshoring company who will do all of the hard work as after all they are the suppliers aren't they?

The nature of the vaiables that exist in this process are such that any foreseen benefits are by no means a foregone conclusion.

Hence the endless vacillation of offshoring and onshoring from partially committed businesses. They offshore because the cost savings are compelling then bring the project onshore when that fails to work as expected.
Then like a salesman desperately over-analyzing his unsuccessful pitches the details obscure the issues. Is it communication or is excessive domestic resistance? Is it lack of processes or tools? Would the project have succeeded onshore?

On it's own, this corporate introspection will not make the difference. To benefit from offshoring an ISV must make the transition from the traditional model to a sustainable model and in order to do that it must change the way that it operates across the board. Then things like offshoring become like bread and butter.

My previous career was in another maturing industry, the courier industry. In my early days, packages were flown to their destinations in the grubby paws of dedicated couriers, often employees off for a quick fully expensed jaunt to a commercial centre. This progressed to the courier companies consolidating packages from many clients in their hold baggage and now they are airlines in their own right. Now, it can be cheaper to send a package to Manhatten than London.

This process of consolidation and commoditisation is utterly inevitable and it is the businesses that accept and adapt that will survive.

Why Outsourcing fails 4. - Failure to construct an effective Business Process

What is a business process?

A business process is a commitment to communicate from the parties involved in a business transaction.

This may be somewhat different to what you will hear elsewhere such as at Wikipedia which has a typically all-encompassing definition discussing tasks, deliverables and other entities.
I feel that these definitions are unhelpful.

If something happens regularly or often in a business which is not defined as an agreed business process by the business, is it still a business process? Or is it just a thing that happens regularly or often?

From my experience, the defining factor for a business process is that there is a responsibility for communication of some sort, even if that is just a note made in a ledger. Project Management practices place great emphasis on communications around milestone events. Without those communications there is no visibility that the event has occurred and so the project cannot be seen to progress.

When an expected communication fails or is overlooked, the relevant information is not captured and so our understanding of events diminishes. If we extend this to the whole project it becomes difficult to understand what our progress has been and what remains to be done leading to missed deadlines and blown budgets.

Often around offshoring, a business process is encapsulated in an application. There might be a bug database, documentation around the product, project documentation and possibly change management software. These things do not constitute a Business Process. A Business Process should be constructed around the way that things get done, not the other way round. It should include the comunication required and outline the responsibility for communication from the various parties.

If you are the owner of an offshore or outsourcing relationship, it is up to you to create a business process to ensure that essential communicatins take place. You will need to decide how things will get done and where the responsibility for this communication lies. You will need to change the processes as the dynamics of the team and what they do changes and you will need to respond to issues around failures of and management of the communication.

Online tools can provide a useful way of assisting the management of those business communications.

The only way to manage effectively is to manage by exception. We know that we have failed if we need to dog the steps of our staff and have the details of their days work recounted to us. This is usually a remedial process.

My priorities are that I can understand what has been done and what we are all focusing on right now. "The longer you can look back, the farther you can look forward.” - Winston Churchill.

The answer for me is a business process that allows me to manage time spent and to have a transparent task list for all of my team. The level of clarity that this provides is a significant change from the old days of picking up where something is going off track and then trying to restore the momentum.

Give sufficient time and thought to your business processes especially around the aspect of communication . Be prepared to constantly review the process and the tools that you use as your requirements evolve and experiment until an effective process is in place. Work with your supplier to keep up with the changing requirements around communication and how you will evolve your business processes to keep up with changing requirements.

The Talent Myth

"In terms of how we evaluate schooling,
everything is about working by yourself. If you work with someone else, it's called cheating. Once you get out in the real world, everything you do involves working with other people" - Richard Wagner, psychology fellow at the Florida State University.