When most people speak of IT project efforts it is very hard to find a positive, enthusiastic response. Unfortunately most of the projects that are considered “IT Projects” seem to receive a negative evaluation the majority of the time.
It is probably unfair to group together all the various types of projects which are not considered engineering or construction-oriented into the single designation as an IT project.
– Is an IT project one in which the current technology for
an organization upgraded or was replaced by a technical “infrastructure”
project?
– Or is an IT project one in which a new technology is utilized to support a
current business operational need?
– Or is an IT project one in which a business process improvement effort to
streamline or improve the current way of doing business is implemented,
possibly with only a very small portion having any technology applied?
Since any and all of the above efforts are often labeled as “IT Projects,” maybe we should better define these various types of projects and then look at what may be the cause(s) of the “troubled” tag that is often applied. In doing so we need to review the various factors of the triple constraint and see if there are ways in which these projects might be more successful in the future.
Technical Infrastructure Projects
Within any organization which utilizes technology to support their everyday operations, there comes a time at which that technology becomes outdated and needs to be upgraded or replaced. These projects are often considered “infrastructure” projects and are often executed by the technical groups which support the organization. Unfortunately very few, if any, of these projects are managed by project managers and are therefore executed in more of an “ad hoc” method.
Of the three triple constraints, the time factor is most often the driving factor in these project efforts. Since the work is usually done internally, or the resources are bundled with the replacement equipment and supplied by the vendor, the cost has usually been budgeted as part of the normal “refresh” or “preventive maintenance” portion of the IT budget. The time or scheduled completion date, on the other hand, is usually determined by upper IT management with little, if any, input from those who are responsible for doing the work.
Since these are not normally managed by a trained project manager, the project schedule, with its activities, dependencies, and estimates, is normally not planned out, baselined, and tracked. Along with this is often the lack of attention to such items as resource utilization, contract management and risk assessment. As a result, not only is it difficult, if not impossible, to report and forecast when various components will be completed, but it is very seldom possible to give an accurate report of actual progress. This lack of clear reporting leads management to lose confidence in the ability to achieve the final results of the effort.
As more and more IT organizations begin to require certification by project managers, major infrastructure projects are starting to have trained, and often certified project managers assigned to ensure that the work required is planned, executed, monitored and controlled in a structured and standardized method.
New Technology Implementation
How often have we received a request for a new effort in which the solution is proposed, before the problem has been defined? I personally blame the airplane magazines for these situations, since the articles often highlight the benefits that various new technologies can bring to an organization without a single mention of the potential pitfalls and problems.
More often than not these “new technologies” have very limited application and therefore when an organization makes a decision to support their current operation they often run into these limitations. Of course, the vendor very seldom will explain the limitations that currently exist since they are relying upon the ongoing development effort within their organization to be able to meet the future needs of the customer. As a result the project effort usually is delayed while additional testing is conducted and/or a “fix” is supplied from the vendor. In the meantime, management holds the IT project team, rather than the vendor, responsible for the inability to provide the solution to the organization, as promised by the vendor.
Of the triple constraint factors, the scope or requirements are often the dominant force, with an aggressive schedule close behind. Instead of really having the time to understand the problem that is to be solved and then determine the most feasible way to address and solve the problem, a potential solution is provided as part of the preliminary scope statement. With the “solution” pre-determined from the sponsor’s viewpoint, valuable project time is spent analyzing the technology capabilities, rather than first understanding what the true requirements are, and then reviewing various solutions based on existing technologies. This often leads to applying this “recommended” technology to a current process, rather than allowing a potential change or improvement to both the process as well as the supporting technology. (This is often referred to as “paving the cow path”).
An example of this situation occurred when a food and beverage organization wanted to utilize wireless technology to enable servers to capture orders in the pool area of the resort. After analyzing the request, the real problem was the need to speed up the ordering and delivering of the drinks to the customer. Upon further analysis, the process of taking the orders and the expediting of the delivery was not really an issue. There were a number of solutions that could be applied to reduce the perceived time delay. The issue was finding a “wireless device” that could be used to take orders at the same time as a tray of drinks was being delivered (since only one attendant was responsible for doing both). Unfortunately the only wireless products that could meet the security standards of the organization were still very bulky and therefore not considered feasible. Even though the appropriate technology was not available, the project was “blamed” for not being able to provide the solution as requested by the sponsor.
Another example of this involved the implementation of a new Customer Relationship Management (CRM) initiative to support the customer sales and support organization.
The organization’s current process was mostly paper-based and would have to be converted as part of the implementation. In addition, the new CRM system would have to interface with two other existing legacy systems, one of which had been around for so long that no one really knew what it did, or how to interface this new information with it.
Needless to say, the conversion process took much longer than originally anticipated and a decision finally had to be made to NOT convert the old data but rather just start using the new system for new customers as of a starting date. This decision forced the sales people to work with current customers using the old manual procedures, and little by little begin entering that information into the new system.
As far as the interface to the legacy system, an initiative was started to look into the cost of the replacement of that system. In the meantime, the data from the new CRM system had to be printed out and manually re-entered into the downstream legacy system.
So much for the benefits derived from CRM.
Unfortunately these types of situations are far too frequent and the overall project effort is negative. Had the requirements and the impacts been addressed before a solution was chosen, the road blocks would have surfaced earlier and alternative solutions could have been addressed.
Business Process Improvement
The most difficult projects that IT project managers have to support are those in which the business has determined that the current processes need to be changed. These are usually more of an 80/20 split with 80% of the effort being directed to “people” process changes and only 20% of the effort being supported by technology. Unfortunately in many of these situations the final implementation results in a reduction of staff. These types of projects are often impacted by either resources leaving the team (or becoming a hindrance to the project and therefore being requested to leave), or the original sponsor or manager changing during the implementation. As a result, the original requirements which have been accepted, baselined and are being managed, are not those of the acceptance team.
Of the triple constraint factors, scope or requirements is obviously the most critical, with resources following closely behind. There never seems to be enough time to determine the real requirements, especially when it comes to how the new procedures will be done, so that either procedures or automation solutions can be written and tested.
The critical resources on projects of this type are most often the business people, not the equipment or material, who can make or break the success of these projects. These business management and staff members must be involved in the discovery of the problem areas and the definition of the new procedures. Once these have been identified and agreed upon, the scope definition or requirements must be signed-off and baselined. The project manager must then ensure that any requested changes to these requirements be subjected to a strict change control process.
Unfortunately the changes requested may be improvements to the original requirements, but it is impossible to hit a moving target. These changes are what usually cause the project to be delayed as well as making it impossible to get final customer approval.
Conclusion
As one IT person considering moving into the project management role asked, “Given all the problems that IT project managers encounter with projects and the fact that the majority of the projects are considered unsuccessful, why would I want to subject myself to that type of life?”
Obviously, unless we work as a consultant, and implement the same type of project over and over again, every IT project is a new challenge. In fact, even when we implement the same type of project, the customer is different and therefore, each project is a new challenge.
Most IT project managers enjoy the diversity of projects that they have the opportunity to manage. They also have learned to identify which factor of the triple constraint is the one to concentrate on through the planning, monitoring and control processes. They then focus their planning and monitoring effort on that factor.
Not all IT projects are “troubled” but obviously the soft skill of managing stakeholder expectations goes a long way in reducing the anxiety, and thus improving the resulting confidence in the project manager to deliver the expected project results.
© 2007 allPM.com
Greta Blash, MA, PMP has extensive experience as an executive and consulting IT professional. Her areas of experience include project management, software product management, information system implementation, with emphasis in the areas of system implementations and conversions, customer relationship management (CRM), data warehouse/business intelligence (DW/BI), and data management. She has developed customized life cycle methodologies for major international organizations as well as training courses in the areas of project management, requirements analysis and data management and has spoken frequently on these topics at conferences world-wide.
This article comes from allPM.com
http://allpm.com/
The URL for this story is:
http://allpm.com/modules.php?op=modload&name=News&file=article&sid=1819
