How to know you’re doomed! (Not just for the nerds.)

Computerworld published a list: “11 signs your IT project is doomed”. Linked here. Interestingly, all 11 apply to normal-world projects as well. I may be biased because I have had my fair share of IT projects. My experience has been that most of them fail because of “Red Flag #4: Users have had little/no early involvement”. Around my parts, our IT department tries to solve problems we don’t have with solutions we don’t need. Lately I have spent hours in meetings sorting out the misdirection and miscommunication months after implementation has gone awry! In a parallel world, I have also been in a lot of meetings with Customers and Sales folks sorting out project details. My exact words in many of these meetings, “Guys, we cannot deliver it in the time-frame you are asking. Why did you sell that without asking me first, I need another 2 months before we even started.”

How many of these sound familiar to you Project Managers? Has your project…

  • Started without Sr. Management approval?
  • Started without a detailed project plan
  • Had Project Meetings scheduled without the key players involved (ignoring scheduling conflicts)
  • Had End Users not involved in project definition
  • Used minimum specifications as the project requirements
  • Tested as an afterthought
  • Never put a recovery (risk) plan is in place
  • Taken expert input and simplified/tweaked without understanding outcome
  • Committed to a Go-live/deliverable date that is on is on a holiday / vacation day / unrealistic time-frame

If you can say that one or more of these look familiar, there is a good chance that your project is going to struggle if it hasn’t already. But why?

I really want to answer ‘why’ with a simplified summary… but I don’t think that I can. Project Management has been the most difficult and yet most rewarding task that I have ever faced in my career. There is an incredible amount of complexity involve in any given project, with thousands of unknowns and an infinite number of outcomes. There is not one solution, there is no single answer. Project Management (IT or otherwise) is as complex as it is fluid. As a result there is no simple summary of what to do right.

That said; there are solutions and there are proven ways to work through the complex problems. There are best practices that each of us can apply to our field, there are take-aways and lessons learned. In my world, we have Lean/Six-Sigma. It’s not the end-all-be-all solution, but it could address many of the ‘red flags’ that the Computerworld article lists out. The five steps below are the standard steps which address many of the above issues:

Define
Measure
Analyze
Implement
Control

Following a rigid process blindly is a waste of time, but following a broad and robust process intelligently can save time, money and headache. What do you think of these ‘red-flags’? Do they sound familiar? How have you addressed or avoided them in your experience?

Cheers!

 

Article Source: http://www.computerworld.com/s/article/9238943/11_signs_your_IT_project_is_doomed?taxonomyId=73&pageNumber=4

Image Source: http://rindkaro.hubpages.com/hub/funny-videos-of-people-falling

 

 

 

 

 

 

6 thoughts on “How to know you’re doomed! (Not just for the nerds.)

  1. Lewis, great article that applies to a lot of situations in my work place. Some of these apply more than others! I have seen far too often in projects (ones that I work on, not ones that I run) where the project manager feels he knows what the users want and speaks for them. This is bad news from the beginning. Also, I have been involved in projects without a project plan. Unfortunately, in my beginning days as a lead on projects, I didn’t recognize the importance of a project plan. I sure as heck learned it during and afterwards! Also, I find that only using minimum specs as the system requirements is a bad idea, as those specifications often do not account for scaling up to allow for additional users.

    In order to avoid these issues now, I ensure I work with end users as well as the various team members to develop my project. Once the project plan is completed and I have buy-in from the appropriate parties, I ensure management is kept in the loop with progress of my projects through weekly status meetings.

    The key to me in my projects is accountability. I like to ensure that the end users are ok with the timelines and the project team members approve of the timelines and the plan as well as their responsibilities. This way, scope creep can be minimized and users/team members can’t feign ignorance with project deliverables.

  2. Although most of these red flags are obvious once you see them I think to many times they are overlooked. I have found that these are most notably overlooked when dealing with R and D projects or internal projects. These types of products seem to be not very rigid and can really cause projects to fail. My company started to incorporate APQP (advanced product quality planning) on all new projects. This was started by the automotive makers and assures many of the red flags are addressed and before moving the project along they need to be documented. At times I find myself dreading all the paper work but when I think of the time before implementing which helps me through the many pages of risk assessments, specification compliance and testing plans.

  3. I was reading this article and it really hit home for me. Right now I am involved in a huge system upgrade which required global deployment of new hardware and a nearly year long testing and upgrade of a database and application set. This is essentially accounting book of record for our internal global asset manager. What scares me is this new idea to use a testing center of excellence. Essentially, this team becomes solely responsible for the testing of all aspects of operation for the application upgrade. The reasoning why this scares me is due to the fact that these individuals have absolutely no business as usual experience. They do not participate in the teams of workings of the functions to which they are responsible for testing. When I heard this, red flags and flashing lights began to go off in my head and this article has caused them to restart. I cannot potentially envision how testing of any deployment can be successful without a considerable engagement of the daily users of such functions. It almost seems like there is a disconnect between the world of reality and the world of management economics and common sense when such movements are made. This leaves the business as usual user in the hot seat as they have little to no say in deployment and assume all the risks of failure.

  4. I was recently on a project that started off in the complete wrong direction. First, all of the work was allocated to inexperienced group members with no insight into what the project was for or how it fit into the larger organization. Then it quickly became apparent that Senior Management was requiring this project, but the Project Manager did not take any sort of leadership role within the project. Group members were forced to network aimlessly with outside departments to get a grasp on what the Project Manager should have been explaining/researching/verifying. The first step you recommend (define) was exactly what the project needed. Had the Project Manager outlined the project better, group members would have felt less frustrated and the project would have probably gotten off its feet better!

  5. Lewis this is a great post because you pointed out many of the things we should look for in a project. I would like to add few things to the list. (1) If you are working on a mission critical project and you don’t have the involvement and commitment of top/senior management then the project is also doomed. (2). If you are working with team with the following complexity cultural distance, geographical distance and language distance then you likely doomed if your tolerance level is low and you refuse to learn other team members culture. (3) If you believe asynchronous communication means is sufficient for complex projects.

  6. Awesome post. I work in a FDA regulated field. So, we don’t fall victim to the most of the issues on this list. However, I can see how any of this problems could derail a project. The two that stand out as being relevant to my company are:

    -Had End Users not involved in project definition
    -Taken expert input and simplified/tweaked without understanding outcome

    We have found out the hard way that our customers need to be involved in the requirements gathering phase of our projects. We have designed and implemented features or enhancements only to find out that they cause problems we didn’t foresee in practice. Also, since we have all matter of experts in our company, in the past we have not always pushed them to deliver a new feature in a more customer centric way. Instead, we have pushed a few in conveniences to customers because our technical experts have not designed a feature well or created limitations. It has been eye opening to see just how differently customers use products from country to country. So, now we make a concerted effort to have understand our customers really work with our projects and have conversations about new ideas. We will begin to have customers participate in sprints demos with the next product release. I think having customers involved prior to implementation is a simple concept that all to often gets overlooked. The customers definitely shouldn’t be designing, but their actual needs have to be fully explored.

Leave a Reply to emmyr598 Cancel reply

Your email address will not be published. Required fields are marked *