Effective Project Management, ITIL and BSM

IT project planners and designers are also those who do the work. Architects don’t lay bricks for example, but software architects do write code. Worse, in most instances the project manager is responsible for requirements, but lamentably few are properly trained or experienced. Thus, almost from inception, the project manager is already contributing to the demise of the project.

Scope creep is especially rampant in IT projects. This is in part due to the relationship of IT to the business. In many cases the business takes the point of view that they must extract all that they can from IT while they can, because the opportunity may never present itself again. Further, non-technical project sponsors can be influenced simply by reading a magazine to demand new features be added to the project. (Few homeowners would consider tripling the size of their kitchen because they know it would mean losing their family room, but business sponsors routinely request IT work similar miracles.)

Roles within the IT organization and an IT project can change dramatically. Most IT project managers are more IT than project managers, and often it is assumed that anyone in IT understands all aspects of IT. Plumbers don’t often convert into roofers, but applications developers do find themselves turning into hardware technicians; just think about your typical voice over IP phone system project.

IT projects often involve many repetitive tasks. Projects are often interrelated and interdependent—really more a program than a project—but they are rarely approached that way. IT projects are seldom linear, unlike construction projects where project tasks execute in a well-rehearsed order understood by all involved.

In order to be successful IT projects require developing new skills and ways of working as well managing—in addition to all the standard project items. For example, not only designing a datacenter but also the processes for supporting the operation of the new datacenter. Yet, most IT workers do not think they qualify for popular generic project management certifications like PMP or CAPM from the Project Management Institute. Nor do they have the time to dedicate to all the niceties that a full-time project manager must address. Worse, they often have an innate (and not entirely unwarranted) prejudice against formal project management.

Most IT projects, as we saw earlier, never complete and most of those that do complete exceed their budget and fail to deliver as promised. Increasingly enlightened organizations take a Darwinian view of projects. Many start, but few are expected to complete. The key is they die after planning, and should be based upon good data so that the true cost for success is not outweighed by the cost to complete successfully.

IT project management can help us in a number of ways since its sole focus is to get the right work done well. Those that realize the importance of project management in general typically have an office of project management but usually do not extend project management training “to the masses.” How can project members possibly contribute successfully without understanding all that is involved with the project? This is a large part of the reason for the high rate of IT project failure.

Another way to look at the abject failure that is IT project management is to think about workload. Inevitably, members of a project team are rarely dedicated to that project alone. Instead, they are typically assigned to numerous projects, as well as day-to-day operational duties. Thus they must answer to many masters, some more powerful than others. I have yet to meet an IT organization flush with human resources; and IT is the most stressful place one can work. One of the reasons why IT is such a stressful place to work is because there is so much work to do. And not only is there a lot of work to do there’s very little room for variation.