Brutal ICT Development Project Classification
By The Grumpy Project Manager
Corporations often have a long list of ICT (Information and Communication Technologies) development project requests that jump on top of each other all the time when competing for priorities. Different departments have their own favorites. Priorities are asked and given, and then changed again. Furthermore, the management sets challenging targets for improving productivity. Several new development request rise from that.
But now we have the button. Pressing that button will stop all development. We press it now. All projects that are going on are terminated. No new projects are initiated. Everybody in the corporation is informed about this. Now we wait…
The first catastrophe?
When will the first catastrophe happen now that nothing new is developed? When would our production stop? When would it be absolutely necessary to make something new? From all the various development requests we have, which are the vital ones? A possible candidate is a request that will fulfill a new legal requirement. If that is not done operations are stopped. That request and other similar ones will be our zero priority projects; must be done.
When will our productivity start decreasing?
Corporations often have quite a stable productivity level. Would it start decreasing right away now that nothing new is developed? Or will it increase now that personnel knows that their IT tools will stay as they are, and will not focus on finding new development needs? What are those requests that will save us from decreasing productivity? If such are found, those will be our first priority projects.
Reaching the strategic objectives
Now a few development projects are going on. Those will ensure that our wheels keep turning at least the same speed they did before we pushed the button. We have a huge pile of development requests waiting. Willing to become development projects. We should now select such projects that will for sure help us reach the set strategic objectives. Gut feeling, guessing and estimating is not accepted, but convincing ROI calculations and measurability are required. Very few if any of the requests can fulfill this requirement. When a closer look is taken, many of the requests are minor user interface changes or workarounds that will not give any real benefits but rather make the IT solutions more fragmented. Many of them would be easy to make. Many of them would make a few persons happy. Some of them would make someone’s work a bit easier. So why don’t we just do them? Doesn’t it make sense to do just something? Anything. But these are not good enough reasons. None of the requests get forward.
The requests are now wandering around on the request yard. Some of them get frustrated and leave silently. Some keep a lot of noise to become noticed. Some start communicating with each other. Do we have something in common, they ask. Alone, as separate requests we are nothing. Together we could reach the set ROI and measurability requests. Some requests from sales, planning, production, procurement and logistics form an alliance. They were competitors earlier. Now they adjust themselves to support each other. The actual IT solution development is forgot for a while and the focus is put on developing the business process. After the business process discussion is done the created common request is ready to try to be a development project. ROI is great. Results are measurable. It is accepted. Real new development is started again. Other similar projects that support well defined business process improvements get also started. These are the second priority projects. Gradually we start reaching the strategic objectives…
The Grumpy Project Manager is a program manager in an international corporation and has over ten years of experience in managing R&D, IT and business development projects. You can read more from the Grumpy PM on his (or her?) blog. S/he can be contacted by email at TheGrumpyProjectManager@gmail.com.