Technology projects are key in the competitive business world. No matter what the internal or external drivers are for change, you need to manage the ensuing projects effectively.
In our previous blog we discussed technology planning – which amongst other things, surfaces a list of technology projects that seem like a good idea to reduce costs, or help grow the business, or both.
This blog is about how to manage a technology project from start to finish to get a good result.
Projects always carry risk and uncertainty. Probably the biggest red flag is hearing the word “new”, i.e. new supplier, new process, new technology. Most technology project problems have nothing to do with the technology itself, but rather come from a lack of planning and analysis, lack of experience, too many assumptions, fatigue, and pressure to complete the job. Taking a step back and looking at these issues again, we can determine that these are in fact people, communication, and process discipline issues. Think about your latest home improvement project or house renovation. What caused surprises, frustrations, extra time and expenses, and an OK (but not great) result?
Multiple business and IT industry surveys note that approximately 1/3 of IT projects fail, 1/3 are ‘wounded’, and 1/3 are considered successful. What can go wrong?
- Lack of initial planning and analysis misses the real business problem or need
- Wrong solution selected
- Vendors or integrators do not deliver
- Testing incomplete
- Data not migrated to the new system correctly
- Users not trained on the system
- Launching when not ready
- The old system is not decommissioned correctly
So what are the important steps?
Plan the project.
The first thing to do after deciding what business problem you are going to solve or opportunity you are going to exploit with the help of technology and automation is make a project plan that includes a business case. This does not have to be long and complex, but a business case should document the following:
- Important activities and work-products you need to get the result you want;
- Preliminary estimates of the skills, time and costs for each activity in the project (and to operate the new system);
- What a successful result looks like; and
- The risks that need to be managed on the journey.
Someone very senior in the organization should be the sponsor and champion of the project. They must commit to make room in their calendar to oversee the project and marshall support across the organization. If this is not part of the plan, you are almost guaranteeing failure.
The amount of planning and discipline should be commensurate with the significance of the project to your business. Consider using at least parts of a generally accepted project management methodology, such as PMO-BOK or PRINC2, and get an experienced IT project.
Project scope addresses: who is impacted, what processes get changed, what data and systems are involved, how long it will take, and what time and money is required. Keep the project scope as small as possible to reduce the complexity and uncertainty of each project. Just like a home improvement project, there will be scope creep so keep it small at the start. The KISS principle is very useful here.
Define and analyse requirements
Once you have a project plan and a clear idea of the end product, dive into the business and technical requirements. Taking shortcuts here will cause a project failure or, at best, overruns and partial success. Existing business processes and technology should be analysed to identify and document the needs of the users (including customers and suppliers) and how things work now. This is not glamourous, fun, or exciting work, and as a result can get glossed over as project participants look to the shiny new toy coming soon. This work needs to be reasonably thorough and use standard templates for completeness and consistency, but it does not have to be exhaustive. Sometimes this work can identify process or system problems that can be fixed, and if a new system is needed at this time. For example, if your current business process and supporting application involves spreadsheets and a lot of troubleshooting, this is the perfect time to adjust your process to correctly implement the requirements, and achieve most of the benefits. This way, time and money and aggravation of a big project can be avoided!
Then the same approach should be used to identify and document the new improved processes and technology changes that will deliver the expected benefits promised in the business case and original project plan. They are also the shopping list for a new system.
Review options
Don’t build your own business applications.
Unless you have a unique business model or other special circumstances, you should look to acquire a business application or suite of applications from a recognised vendor that has a track record in your industry.
Do not build your own business applications. IT solution vendors have spent lots of time and money refining their packages to support efficient business processes. For Operational Technology projects, the vendor and solution space are less mature (remember what we said about “new”?), so you may end up putting various components together yourself (again, more risk). The requirements you listed previously will allow you to identify a short list of candidates that appear to address your problem and ask them how they support your requirements and keep you in the driver’s seat at this crucial stage. If you start talking to vendors without having done this homework, you could be seduced by glitzy presentations and sales talk that benefits the salesperson and the vendor – not you and your business! Embrace configurability of the business systems to meet your requirements, and resist code customization which will be a never-ending headache to re-apply when vendors make updates to the package code.
The other big decision today is whether you will bring the solution in-house or “go to the cloud”. There is no right answer here, just pros and cons and different risks and costs for each path. An on-premise licensed package has one set of capex and opex costs and risks for implementation and continued operation, and a cloud solution has a different set of costs and risks. Be careful of the attractiveness of the ‘no up-front’ capex and low operating costs of the cloud. Many large and sophisticated companies and IT departments have had unpleasant costly surprises caused by unanticipated increases in users and transaction volumes that drive big bills from Cloud Service Providers (and maybe your telecoms provider to haul all that traffic to and fro). Get a good grip on this before you commit to a path.
Implement the business or operational system and supporting infrastructure
Regardless of a solution that is on-premise or in the cloud, you need to install and set up the supporting IT infrastructure and the application system in a secure manner according to your requirements. Your IT team need to test the operation and security of the new system, and work with users to load data from the old system. Users need to test the business functionality including error handling. Again, the requirements defined previously are critical here to create tests of how transactions get entered and approved, masterfiles get created, and correct reports get generated. Testing is another unglamorous and arduous task that can get pared down if the project is over budget or late. Do this at your own peril. Once the core project team users have tested the system and signed off that it works properly, you can then train users on how to properly operate the system and change their processes to adjust to the new way of working.
Project Review for lessons learned and pinpointing OS issues and disposition
Once the new system is up and running and settled in, close the project down by doing a post-implementation review. This can be brief but useful. Meet with users and IT and consider:
- Are users working with the system?
- Is the system operating as users believed it would?
- Is the system efficient?
- Have enhancements been requested since project completion?
- What would users change if they could?
- How do actual project costs and time and operating costs compare with budget?
Good lessons learned for the next one!
Be careful of the “Iron Triangle”
The ‘Iron Triangle’: there are three basic goals of a project – time, cost, and scope/ quality. Experience has shown that these are all closely related in a project, but it is very difficult to achieve all three. For example, apply these questions to your project:
- If you insist on a deadline (time), what is the extra cost or reduced functionality you will accept?
- If you lock the budget (cost), how much more time will the project take and where are we cutting corners?
- If you add functionality (scope), what is the extra time or cost?
Again, remember your last home improvement project.
Use a Launch List to authorize ‘going live’.
This is a list of critical factors or outcomes that must be true before jumping off the cliff and using the new system to support your business. It should be created at the beginning of the project based on the most important requirements, and carefully updated as the project continues. The list should include points like:
- Are the masterfiles loaded and checked;
- Have the users been trained;
- Did we find any critical errors;
- Has the old system been turned off, etc.
Beside each launch list point should be the name of the person responsible, and they should sign-off that their critical point is OK. This forces explicit declaration that the important things have been done right before going live. At this point, those responsible realise their name and reputation is at stake. It causes people to think. It is powerful.
Have a fall-back plan
After launching the new system, don’t throw the old system out for a few months. Document how transaction data and masterfile changes entered into the new system can be migrated back to the old system if things go off the rails.
Summary
Technology projects are challenging because most organizations do not do them on a regular basis. As a result, most users, and even IT people, lack the expertise and experience necessary to plan and execute these ventures well – just like a home renovation project. So be thorough in your planning, get help where you are unsure, and accept some surprises along the way.
