I find the success rate of large-scale IT projects astonishing. As discussed in class any project with a budget greater than $3M or in the works for more than 18 months is almost guaranteed to fail. It would seem that getting 40+ people to work towards a common IT-related goal and complete it on-time, on-budget and to spec is nearly impossible. Should the project be even bigger and more crucially important to the success of a firm, it will have absolutely no chance of successfully being completed on time, budget or to spec.
Regular, non-IT related projects do not suffer this same dismal success rate. Skyscrapers are built all the time, using hundreds of talented construction workers from dozens of trades and they are easily able to forecast timelines and costs while building exactly to architectural plans. In comparison with the IT industry the construction industry can also boast projects that last years and costs billions. Yet if every time a major casino was built of the Las Vegas strip it was guaranteed to take 5 years longer than expected and cost two to three times as much as forecasted our world be devoid of super-structures.
To an outsider it could be said that the construction industry is a much simpler list of trades, and that a professional dry wall installer doesn’t have nearly as tough of a job as does a graphic designer. However managing hundreds of dry walling professionals would come with its own challenges, in general these are uneducated professionals with significantly varying levels of professional conduct. Further while some trades like installing dry wall are relatively simple, the time and effort required to plan and execute a major structure’s plumbing and electricity are enormously complex. Yet again, the construction industry is managed with a completely different set of expectations.
One could argue that the reason for IT Project Management’s dismal track record is the consistent innovation that is attempted in this sector. So rarely are major projects with hundreds of programmers working on any type of project that has been done before and as such they cannot so accurately forecast their timelines or costs, further they can’t build out an architectural plan nearly as precisely. However I still believe that IT project managers could learn a few things from the far less sophisticated construction industry.
In the construction industry when a major construction project is planned there are massive teams of engineers and architects scouring over every detail of the plan. They then bring the project plans to specialist engineers with experience in planning electrical and plumbing and then modify the plans accordingly. Every major detail of the structure is planned years before ground is broken, then small scale models are created of the expected final project. Stakeholders are consulted, needs and requirements are noted, then they are integrated into the plan and finally reviewed. While small changes are much more easily managed, and don’t necessarily have greater ramifications on the rest of the construction the later changes are generally cosmetic, rather than structural. The construction of a 60 story skyscraper would never get 35 stories high before the owners decided that it should actually grow to 80 stories. Yet, in IT project management such monstrous structural changes seem to be acceptable. When a project is 40% completed and only small cosmetic modifications are realistic, it still seems to be common place for major companies to change their desires for an end product and demand conformity from their team.
The other area where I believe construction projects seem to have a leg up is the vast number of project managers that are on site at any given time. Every worker on a project can expect that at some point, almost every single day, someone is going to walk by and see what they are working on, how their work looks and whether or not it is up to code. On the contrary, because programmers are so highly educated, because they are designing something new and since there is no code to follow, they are given a large amount of trust to complete their projects and submit them at a specified date. In projects with several thousand programmers, each with their own little computer screen which is hard to walk past and casually inspect, there is an incentive for programmers to pretend to be working. There are enough other programmers that are also working on debugging code or creating graphics, that it is easy to put your head down and take a lazy day every now and then. While it may hurt morale, perhaps a shorter leash and more frequent checks of output would help major IT projects move forward in a more timely fashion.
Prepared by AI
Posts
