Geeks With Blogs

News Google

Nick Harrison Blog<Nick>.Next()

I recently worked on a project that failed.   There is no other way to put it.   The project failed!    It’s a hard thing to admit.

There are many reasons why bad things happen to good projects.   There are many reasons why despite our best intentions, not every project is successful.    There is always plenty of blame to go around.   The business market changed.    The technology changed.   We could not find the right resources.   Critical resources left.   The project lost funding.    The business lost interest…

Many of these reasons can be boiled down to, IT didn’t know what the business needed and the business didn’t know what IT was doing.   In other words requirements were not well documented.

From my recent experiences, I have come up with the following red flags to help you identify when your project might be in trouble

Red flags

·        If you have never met your subject matter  experts, your project might be in trouble
·        If there are no subject matter experts, your project might be in trouble
·        If new requirements are deemed critical but ignored for the sake of the schedule, your project might be in trouble
·        If a user that you have never heard of claims to be a project sponsor, your project might be in trouble
·        If the requirements change so much from one week to the next that you feel like it’s a different project, your project might be in trouble
·        If new people join the team and its weeks before you even meet them, the project might be in trouble
·        If you look around and there is no one to QA your code, your project might be in trouble
·        If you spend more time deploying than you do coding, your project might be in trouble
·        If the same project has failed over three times already, your project might in trouble
·        If no one can succinctly state the business needs being solved, your project might be in trouble
·        If you have already deployed once, but still second guessing the platform, your project might be in trouble
·        If you can submit last month’s status report for this month and no one notices, your project might be in trouble
·        If you can’t tell last month’s status report from this month’s, your project might be in trouble
·        If you have worked on the project for over a month and still don’t know where the database is, your project might be in trouble
Guidelines:

·        Write requirements down
·        Don’t get bogged down in format or structure just content
·        Get consensus that what you are working on is what needs working on
·        Talk to as many users are you can.   They rarely will agree with each other
·        Deploy new functionality as often as you can so that the users don’t worry that you have forgotten about them
·        Keep deployment schedules spread out enough so that you don’t get bogged down in deployment overhead
What red flags have you seen?   What are some guidelines that you have seen work?

Posted on Wednesday, January 9, 2008 9:02 PM | Back to top


Comments on this post: Your project might be in trouble if …

comments powered by Disqus

Copyright © Nick Harrison | Powered by: GeeksWithBlogs.net