coneblog

In starting a new project, I try to identify the main risk – and structure the project accordingly. Most of the time though, it is the same risk.

I do a wide range of projects in a wide range of industries, and I often participate in a project that is something new for the organization. If it is an incremental project on an existing system, they usually don’t need me. So I’m often doing a project in a new functional area, or applying a new technology (mobile, data mart, etc) to an existing functional area. And these are usually operational systems, rather than administrative systems, in that someone is trying to improve a business process through automation.

In these types of project, the primary risk is always the same – the risk of doing the wrong system.

By the wrong system I mean successfully implementing the wrong feature set. By wrong feature set I mean missing that subset of all possible functions and features which are the minimum necessary for an operationally viable system.

Simply put, the primary project risk is that the feature set you deliver doesn’t match or support enough of the business function to be viable.

Does this sound unlikely to you? Are you confident in your ability to understand a business function and implement a feature set to support it? So am I, but when I look at the projects that I’ve been involved with, the record tells a different story.

My guestimate is that approximately half of the hundred plus implementation projects that I’ve been involved with were ultimately not operationally viable. There were a wide range of reasons – sometimes the technology just wasn’t appropriate or ready. But often, the feature set we identified and implemented didn’t support enough of the business process.

Sometimes the needed scope was way beyond the available time or budget. But often it was possible. In short, we implemented the wrong system.

There are many causes for this. A common cause is Management control of the feature set. User management thinks that they know what is needed, but often they are too far away from the details to get it right. In many organizations the staff, or workers don’t have a voice in the requirements process, and their needs go unheard, and unimplemented.

Getting users to use a system, especially if they have an alternative, is a delicate process. It requires listening, observation, and attention to detail. Often it is the little details that make a task easier that make the difference between acceptance and failure.

Then there is the perennial problem of “cost of data entry”. In many applications, the users best positioned to enter accurate data into the system are not the users that derive the most value from the data entry. The value is usually downstream. The problem, then, is to get the entry users to do the extra work of capturing the data for the other users, with little benefit for themselves. When features like these are implemented without a corresponding set of features to create value for the “entry” users, the data doesn’t get into the system, and the overall value proposition falls over.

So what is the answer? The answer is that there are no easy answers. If there were, I’d write the book, and retire. But here are my guidelines. I go into every project with a healthy awareness of the “wrong system” risk. I seek out those users without a voice, and try to understand their needs. I try to include all parties in JAD or Design sessions. I attempt to capture the benefits of the system in a very inclusive way, and seek to craft a solution that addresses the whole value proposition. I am aware of possible data transfer dis-economies, and try to build in balancing value. I try to use incremental approaches that will make clear to all where the holes are in prototype forms.

Even so, far too many projects fail. So be aware of the risks – don’t implement the wrong system.