Imagine undergoing some serious surgery at your local hospital. The nurse tells you that they are all excited about your surgery. Your surgeon is very famous but quite new to the hospital and the surgical staff has never worked with him before, and they are not familiar with his operating room procedures. Further, there is exciting buzz about the new operating room technology that was delivered just the day before that will radically change how your operation is performed. You will be the first person they try it out on.
Farfetched? Of course it is. No one would ever put a new surgical team together with new technology and new operating room procedures with a real patient. It is a scenario for disaster. A new systems development project? Well, it’s done all the time, isn’t it!
IT is abuzz. Senior business management just approved the development of a new expanded order management system. They approved a budget to purchase a new No-SQL database, 70 new workstations, a half-dozen servers, and hire seven new programmers and analysts. This will give IT the opportunity to try that DevOps approach it has heard so much about.
See any parallel?
New IT technology is expensive. Just purchasing one database management system can set an organization back six figures even before the required new hardware and staff training. Many IT organizations cannot afford to purchase such items out of their operating budgets. Big-ticket items have to wait for the big systems development projects with their business management funded big budgets. New, high profile projects, with funding from project sponsors, can be a time of renewal for IT. That’s the good news. The bad news is that all those new items increase the risk of project failure.
Go back to the surgery example. Being operated on by a famous surgeon is good. Having the latest operating technology is also a plus. Keeping hospital procedures up to date is a sign that the organization is trying to do better. Throwing them all together for the first time—not a good idea. Yet, that is exactly what IT does. Given two projects, one a 3-month, 9 person-month, internal to IT inventory system, and the other an 18-month, 200 person-month, business critical order processing system; which gets the tried and true tools and techniques, and which gets the high-risk, brand new tools, and techniques? It’s insane.
Ideally, you want your best-trained staff, using tried and true tools and techniques, on the most important projects, and you want to train staff and try, test, and learn how to use new tools and techniques on small, ideally internal-to-IT projects. How do you do that given that IT can only afford to purchase the new tools and techniques when undertaking a new business-sponsored project? The accompanying diagram frames the conundrum.
The four categories in the diagram just might hold the answer to IT’s problem.
Category 1: Missed Opportunity
Unless IT has great staff sitting around doing nothing, wasting the best people, experienced in the use of IT’s methods, techniques, and tools, on non-business critical applications is a waste of resources. The risk is bored staff and senior management wondering if systems development is overstaffed.
Category 2: Best Foot Forward
This category is IT’s raison d’être—its reason for being. Being able to staff a high-profile business critical application with IT’s best and brightest using technology they are familiar with is the ideal. It’s the lowest risk with the highest reward.
Category 3: Learning Experience
This is IT boot camp. It is the ideal place to train inexperienced staff as well as try out new methods, tools, and techniques. The challenge is finding the funding to bankroll the low priority work. This is a good test of IT’s ability to sell systems development investment to business management. There is also a silver lining for IT. While IT is working to automate the business, it is often one of the least automated departments in the business. Certainly a case of the shoemaker’s kids. Because of either priorities or budgets, IT is one of the most labor-intensive departments in many organizations with numerous opportunities for automation.
However, getting approval for Category 3 projects can be a challenge. Some strong IT management, a well prepared business case, and a good project champion should grease the skids for IT to identify, approve, and fund Category 3 projects, even if they are not kicked-off right away. Why not start them right away? Because the smart IT manager will always have a number of Category 3 projects waiting in the wings for just the right time (see below) to launch them.
Category 4: Suicide Alley
Run! The risk of failure is very high. This death march is often predetermined by the inability of IT to sell to business management the need to invest in new staff and/or technology before committing the farm.
Why are there Category 4 projects? The answer is because that is how funding works. IT wants a new database management system and four servers to support it and senior business management says, what for? Why can’t you use what you have? However, if senior business management wants that exciting new business product and IT says, yes, we can do it, but we will need a new… You get the idea.
What Can Systems Development Do?
There are no great answers, but a few not-so-great-ones can provide some help. It’s unfortunate, but Category 4 projects will not simply vanish on their own. However, there are a few things IT can do. The remedy is risk shifting, turning that risky Category 4 project into two projects, a Category 3 followed by a Category 2. The idea is to shift the risk from the Category 4 project to a Category 3 project. Below are three options in order of preference.
Option A. Schedule a non-business critical project just before the business critical one.
Because many non-business critical projects are short and business critical projects long, it might be possible to schedule a non-business critical project, containing the new staff, tools, or techniques, before the business critical project kicks off. A 6- to 8-week low-priority project might just provide the training and tool familiarity staff need to get up to speed for that business critical project, thus turning that Category 4 disaster into a Category 3/Category 2 win. This is why the smart IT manager always has a Category 3 project waiting for the right moment.
Option B. Run a non-business critical project simultaneously with the business critical project.
Sometimes the business critical project needs to start immediately. IT might have to start the non-business critical project in parallel with the business critical project. Not ideal and the non-business critical project will probably negatively impact business critical project schedules, but it is unavoidable. The more disparity between the non-business critical and business critical schedules (the longer the business critical project schedule) the better. This option is not as good as Option A but it might have to do.
Option C. Bundle the Category 4 project with a non-business critical Category 3 project, doing the non-business critical work first.
If running a non-business critical project before, or in parallel with, a business critical project is not possible, then the best IT can do is to find a non-business critical project related to the business critical project, and bundle the two projects together making a new single project. Then the non-business critical tasks could be tackled first, using the new staff and new technology, allowing a de-facto training period before the business-critical tasks are started. The challenge is finding the right non-critical project that, from a user perspective, fits in well with the critical project, can be built before the critical project work, and the business is willing to fund.
The project manager is faced with many technical and personnel project issues but perhaps the most important success factor is risk management, in this case shifting risk from business critical applications to non-business critical applications. It is hard to find a single action that can benefit the business, IT, the project team, and the project manager. This just might be one of them.
George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).
