How to drive a successful technology project

When I think of a successful technology project, I think of a successful software implementation. I suppose there are other kinds of technology projects out there, but I am going to focus my attention on software based technology projects.

It is important to understand not all technology projects are alike. For example, a technology project that affects many people is very different from one that affects only a few. In fact, when starting a technology project, I would try and understand the project along these lines.

Is it supporting a mission critical process?
Is the underlying process prescriptive, descriptive or predictive?
Is the underlying process well defined? Does it suit the needs of the future?
Is the process fixed (as in transactions) or changes over time (as in decision support)?
How many people will use the new technology?
What are the data needs for the technology? Is the data available?
What are the desired outputs from the technology?
How will we define and measure success?
How will we define and measure failure?
Whose buy-in do we need to start the project?
Is the Return on Investment (ROI) well defined?
Etc.

The list of questions above is not exhaustive. I am sure there are other good questions to ask. Since there are many different types of projects, it is difficult to establish one set of criteria for success. What follows is a series of guidelines to consider.

Achieve clarity on business benefits: It is very important to clearly define the expected business benefits and use that as the guiding light. Technology projects, especially long ones, can easily be caught up in technical objectives while not meeting the business objectives. This results in a situation where the ‘operation was successful but the patient still died’. Keeping the eyesight trained on the business benefits prevents this situation.

Get appropriate buy-in: Implementing technology that affects multiple people, departments etc. can be easily sabotaged by only a few of the many people involved. It is important to get the appropriate buy-in from all levels. Management buy-in helps drive it, but you also need buy-in from IT and user communities. Sometimes, this requires doing a little extra for one or two ‘tough’ constituents. If the goal is appropriately defined at the business level (see point above), then these types of minor detours can be easily accommodated.

Match the approach to the underlying process: it is important to use the right tools for any job; in technology projects, the approach should match the underlying process. For example, if you are implementing software to help with basic transactions (think ERP systems), then you can take an approach that defines all the requirements upfront and then goes to deliver it. If, on the other hand, the project is about decision support, then the list of requirements only have limited meaning and should be interpreted more generally. This is because, in decision support, requirements become clearer as they are delivered and users try to use this technology. This is by far the most common mistake I see in technology projects. The key learning from this is to define requirements at the level of detail that supports the business need and not any more.

Plan simultaneous process improvements: A lot of companies (and consultants) promote this methodology that you must fix your processes before you implement a new technology. The thinking is that if your process is wrong, the new technology will only make you do the wrong thing faster. In my experience, this is not ideal. If one wants to make the whole experience better, they should consider making process and technology improvements simultaneously. The technology then becomes the enabler for the process change and both changes then have a better chance of succeeding.

Avoid the big bang approach: Unless you are doing the technological equivalent of constructing a building, there are opportunities to use parts of your project deliverables while other parts are still being worked on. Use these opportunities. Define business releases such that you can deliver usable functionality at set intervals. This increases buy-in, and allows correction to any mistakes or for users to reconsider their requirements early on in the project.

Plan for contingencies: As I have written before, in this day and age, project planners can easily mistake the precision of planning tools for accuracy of the plan. Technology projects get a bad rap when they do not finish on time. Planning for appropriate contingencies in the timeline can ensure there are no such surprises. This can be helpful in claiming success at the end of the project.

There you have it. Some of my thoughts on what it takes to make a technology project successful. If you have other ideas, I would be interested in learning those.