Brutal IT Development Project Classification
By Vesa H Autio
Corporations often have a long list of IT 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…
And what’s in it for a grumpy project manager?
Should development managers and development project managers become worried if all development is suddenly stopped. Not really, as full stop is the best that can happen. Continuous development is necessary if a company wants to stay in the business, so after the dust has settled development continues. But as a result of this brutal classification we’ll have a limited amount of important projects. Important projects are planned well and get adequate resources and attention. When stakeholders understand and accept the objectives there is enough information and support available. Important projects improve corporate spirit and give real, measurable results. Important projects are demanding and in the spotlight, and therefore fun to run.
Vesa H Autio is a solution manager in Consolis, and a senior advisor for a project management consultant company Arito-tsm offering JaVePro training and research services. He has over ten years of experience in managing IT, R&D and business development projects. You can read more from Vesa on his blog. He can be contacted by email at firstname.lastname@example.org.