IT Projects Gone Haywire

IT Projects Gone Haywire

We’ve all experienced an IT project that has gone haywire

Often we end up scratching our heads asking, who is at the wheel on this project?   This is especially true in IT Software Development projects where many components are in the mix, everything from corporate leadership giving a mandate as to “this is the top priority”, to department managers who want nothing of the project, because of all the other things going on, to the end users who resent the fact that they see the end result as more work.

What is the project background? What is taking place here?   How is this be mitigated if not completely resolved?


Some time ago, I was deeply involved in an IT project where this type of project was in play.  The leadership laid out the project as highly important to the overall business strategy and future business intake.  Given that, it would seem that managers would be not only involved but highly instrumental in ensuring this project was a success.

However in this case the department manager is not only scarce in involvement, but isn’t involved at all in defining and driving project tasks and deliverables, or in issue resolution.   Secondly, the IT manager isn’t involved to the extent of driving IT tasks and deliverables.  Neither had much direct involvement to this project.   For both it was more of a mandate and must do, but do so at a minimum.

Right off, this project seems doomed to failure.  Given lack of involvement from the department manager and IT leadership, it would definitely seem that at Phase 0 of project management, the project assessment of readiness, this project should never start.


The project is a MANDATE, meaning the corporate leadership as decided this is a MUST DO project.  Often times these types of projects are resented by the areas most affected or impacted.  It would seem people would be supportive, but the resentment comes where the existing workload is not reassigned. Project participants are frustrated that this is over and above their existing work.   For a financial analyst, those daily reports, and monthly corporate summaries must still be completed on time.  Yet this same person is to give 20 hours per week to the project.

Next is whether this is seen as a good move by area management.  Oftentimes new software will take people out of their comfort zone.  That spreadsheet that I spend 30 hours per week updating works just fine.  If I have to go to a new screen, it will take me a long time to set this up.  People don’t consider and see the long term potential in hourly savings.  The new software will reduce that 30 hours of spreadsheet updates to 2-4 hours per week of updates. 

Lastly, the area management and other staff may see this change as a threat to their livelihood.   What does this mean?   Well in a past project, I developed a communication software package that automated the sending of mortgage banking certificates to agencies in Washington DC.  A Vice President presently handled this transmission from his PC, using outdated communication software.  He spent as much as six hours per day transmitting mortgage banking certificates.  He was totally against a change here.

The new automated system completely took this out of his hands, and he spent maybe 10 or 20 minutes a day viewing transaction logs where certificates were sent.  Not necessary, but he was able to keep his finger on the pulse of the system.  The savings was immense to this VP, and restored six hours to his daily schedule.  He had time for other things, more important things related to this business.


For software development projects to be successful, at the very least, the KEY DEPARTMENT leadership member MUST be involved, to the extent of OWNING the project.   What is a KEY DEPARTMENT?  This is the department that is most affected, will be the user or primary user of the software application.  

An IT software project cannot and MUST NOT be viewed as an IT project.  Having said this, IT management MUST BE involved to the extent that they are essentially Cohort with the department management in this project.  This means that the IT manager MUST provide enough guidance and leadership to the department management, in project steps, and activities, and even in problem resolution.  The IT Manager cannot and must not be a bystander.  Both the area manager and the IT manager have ownership in making a project a successful project.


In the information gathering phase, people MUST be involved.  That means not only those managing the project but those that are impacted by the project.   Getting input from all will assist in creating ownership of the project deliverable.  This is a key area that helps to ensure success. 

People cannot hand off a project to the IT developer and say “Here it is, do it and let us know when it is done”.  Again, that is total lack of ownership. Passing off the project to a developer oftentimes results in unused software, as people didn’t take the time to be involved or were excluded from involvement, and didn’t provide the necessary inputs.   Ownership by the end users is paramount in a successful software project implementation.

Time is always a critical issue to people.  In project based activities the mangers can get sidelined with other activities.  This is nothing unusual, and the managers must not forget their responsibilities to the project.   When problems arise, these managers must be in the lead in problem resolution.  If/When the tasks fall behind, these managers must understand why and make adjustments to mitigate the future occurrences.

Implementation of the software is never easy and requires much time and effort to be successful.  Implementing a software project deliverable is not about IT installing the software and then saying Sayonara Sucker.  Much support is needed in training and education to ensure success.  The same views the managers may have had about this project may also be shared by the end users.  The end users must be educated to the extent that they know and understand the data they see.  They know what it means and they know how to respond to different results.   The lack of education here often results in project failure, right at the very end, simply because the time was not taken in a most important area.


These are but some items that will assist in success when a project is mandated from corporate leadership.  Granted most projects come from corporate leadership, or some area management leadership.  Regardless, the same issues and tactics apply.   Considering these items when taking on a software development project will go a long way to ensuring success and a successful implementation.

Leave a reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • IT Silos
  • slow network
  • geek speak
  • outsource CIO role