As a highly interested project stakeholder, you know the litany of good advice for effective projects. Find a sponsor, plan well and ahead, define your goals, put love into design, take milestones as STONES. All well and good, yet the IT project – the good-looking little sister of the classic project – always seem to have it a little harder.
The heavy burden
Often cited, The Standish Group’s CHAOS study is probably the best known study on IT project success. According to it, in 2015, nearly 20% of projects did not reach the end of the project because they were cancelled. Since the projects no longer exist due to the termination, but the companies still exist due to their participation in the survey, we can assume that the reason for the termination in most cases is to be found in the project or its direct environment. Assuming an average Homo Sapiens Projectensis – forgive me this favorable expression of total impecuniosity in dead languages – it is on average neither the company nor the project participant who is responsible for the failure. Are IT projects simply different from the other children?
With a comparative study for projects that do not focus on the IT area, it is difficult. The study of the University of Kassel on the PM maturity level seems to me to be the most suitable, even if it can only be used with restrictions for our purposes. In the three-stage CHAOS classification, the stages can be very clearly distinguished from each other by criteria such as termination or full achievement of objectives. This cannot exactly be said of the five-level goal attainment scale plus a 10% white-not portion. In addition, the voluntary participants of a study with the topic „project management maturity and project success“ may not be a representative cross-section. On the other hand, we have many industries among them and after all a small to medium project (6-20 members) and company size (85% large companies).
According to this study, a good 70% of the projects achieved their goals to a high degree (4 or 5 out of 5 levels). As prefaced, I am aware that this statistical basis is shaky, but it is all we have. So let’s assume for simplicity that industry projects in general do better than IT projects in particular.
What could be the reason? An IT project has idiosyncrasies that other projects have limited exposure to, and I’m making the case that these idiosyncrasies spoil a bit of the success rate for us IT project managers.
Cost structure
First and foremost, IT projects are primarily personnel projects in terms of their cost structure. Certainly, depending on the orientation, the hardware introduced (data center set-up) or the licenses to be purchased (SAP introduction) can devour quite considerable sums, but the typical IT (software) project does not scale with the license or hardware costs, but with the complexity of the organization. That means, an additional quantity of 100 users costs (in the asset) according to the standard price list on the license side (in the common mix) a medium to high 5-digit sum. However, 100 additional users (e.g., an additional location, or a larger department that was not previously taken into account) will result in considerably more expense in terms of the project team’s personnel costs. This certainly does not apply to every project (think of very large and very homogeneous structures, where 100 or 1000 more users hardly make a difference because they fit into the existing global design), but it can be generalized with good will for the average IT project customer.
And why this steep thesis? Well, anyone who has to procure steel girders for an (asset-intensive) bridge construction examines the investment, the construction plan, the contracted company and the schedule very closely. But if the proportion of the project value that can be capitalized far undercuts that of the value that cannot (so clearly) be capitalized, the audit is not quite so straightforward. Certainly, in both cases it is important to have a competent partner at your side. However, the dependency on the partner’s experience and methodology is many times higher for the cost and time planning of an IT project. Since the specific pitfalls are often also product-specific, the residual amount of capable and product-experienced project consultants is much smaller than in a typical construction project.
Transparency
For the same reason, it is much more difficult for the customer to evaluate the concrete progress of the project during implementation. The customer usually does not have the in-depth know-how in-house, one of the main reasons why he turns to an external partner. However, this leaves customer monitoring on somewhat shaky ground. To this end, of course, IT also creates corresponding milestones at which the customer carries out partial acceptances and selectively and specifically checks the system status. However, this is only comparable to a limited extent with an on-site inspection at a supplier for a „classic project“. In short: if the bridge is 70% complete, I can see that. With the ERP system, this is not so easy.
So, as in IT service management, the most important thing for IT projects is to ensure assessment competence on the part of the customer, who develops suitable measurement and assessment procedures together with the external supplier in order to jointly track progress. If deviations are identified, the project organization must be willing and able to respond.
Butterflies
In addition, the ERP project (compared to less ambitious IT projects) has an unheard of level of integration between processes, application areas, and therefore business departments. This complexity must be fully under the control of the project organization at every stage of the project, from initiation, through planning, implementation, testing and acceptance. If I lose the overall view of the phase changes (especially between design and implementation), it can happen that a careless switch in PP (SAP Production Planning) shatters my beautiful PS (SAP Project System) process design.
Following the chaos theory, when several colleagues work on the same system in integrated processes, the overall solution tends towards an ever higher level of disorder. However, each design paradigm and setting must be aligned with the others, and this requires an extra dose of project governance in terms of communication and documentation. To accomplish this task, it is recommended to have one or more software architects in addition to the project manager, depending on the scale, to watch over the individual process areas and their workstreams and ensure that they are integrated.
Frankenstein
„Nothing is so painful to the human mind as a great and sudden change.“ (Mary Shelley, Frankenstein)
And another set of problems applies to IT projects in particular – IT systems in themselves are fundamentally extremely flexible. SAP also allows me to give free rein to my customer-specific will in the code. Of course, every organization also resists adapting its industry-specific and highly requirements-driven processes to any product standard.
However, one quickly loses sight of something here: the product standard is not arbitrarily chosen, SAP software has always been a solution that was developed at and with the customer. A standard solution with industry-specific features, whose strength lies in the fact that it does not have to be tailored individually for each customer. What exactly differentiates my headlight production from other series manufacturers in the automotive environment? I can let off steam in customizing, structures and master data – but I shouldn’t touch the code.
Because with the individuality that is lived, some unexpected pitfalls come my way. On the one hand, when modifying the standard (let’s call them „Y“) as well as when using additional programs (let’s call them „Z“), I have to ensure the smooth integration of my „Y“ and „Z“ with the standard processes in SAP and with the surrounding systems. This is because I can only assume in the standard that the SAP processes and structures fit together, and exchange data cleanly via the standard interfaces. In the case of „Y“ and „Z“, I place a lot of trust in the developer that he has all the SAP dependencies (what do I have to consider) and design principles (why do I have to consider it) in his head.
„Y“ and „Z“ also have a high price in daily change and incident management. Even complete and up-to-date documentation does not save me from reconciling the solution with the SAP standard every time I make a change. This applies to the import of SAP Notes (code corrections) as well as to the implementation of SAP Support Packages (bug fixes) and Enhancement Packages (functional updates). In addition to the often considerable additional effort, this often results in a risk assessment for developer resources. Is my developer able (is he still there and does he have the time?) and willing (does he understand the extent of the problem?) to provide me with long-term and comprehensive support, as SAP does with its maintenance contracts? If I cannot assume this with certainty, I will have a massive problem in an average SAP lifecycle of 15 years and will have to face the question of how important the availability of my processes implemented in SAP is to me in principle.
The argumentation listed about the oh-so-difficult IT projects is in no way intended to relieve us IT project managers – we are still the maker of our (and the customer’s) luck. However, it can sensitize customers as well as service providers, because in a difficult environment there is a special responsibility to accompany the customer methodically and professionally through the project.
Here’s to success,
