IT Project Success: Starting Early - How, Who, What, When and Why

Yesterday was about IT Projects being successful only 34% of the time. Today I’m blogging on how to being a IT Project with success in the air, our goal in the IT industry should be to increase that 34% to 90 plus percent.

To succeed we need to get all the IT project members involved early in the project. We need to plan the resources early, get them on board during the planning. Team leads should be involved in planning out and setting up the project team. Business Analysis, Architects, System Designers, Developers, QA testers/engineers, Release Manager, Trainers, Technical Writers, Help Documenters, there maybe other’s that your projects require whoever you need get those resources planned. If there are tools needed by any of the teams or the whole team plan for training. Plan your process whether it be Agile or XP you’ll find processes always vary depending on the project, the resources and the project type.

Once project planning has is done, get the resources on board for the first step, requirements review or as I like to call it the Design meeting. All teams should have representation including the business in the Design meeting. This meeting(s) is where all teams participate to;

  • discussed and learn the requirements put forth by the business,  – build expertise of requirements across all teams
  • validate requirements - can we do? - are they valid?
  • learn about the proposed design and architecture
  • identify requirements that are system needs versus functionality
  • create a listing of scenarios from the requirements
  • work out an initial build schedule and what scenarios will be in each build
  • how can we best test, what types of testing will be needed
  • what are the time-lines, are they realistic, if not now is the time to flag
  • is there resources we don’t have, expertise we need

A lot of discussions along with learning happens in the design meeting(s). The list below is what you can expect out of these design meeting(s):

  • team of experts in knowing and understanding requirements
  • team relationship building, respect for other team/people expertise
  • communicating to obtain a shared understanding
  • eliminating miss interpretation of requirements
  • teams going away with needed information to further plan
  • better time-line estimates – more realistic
  • proposed build schedule(s)
  • identified missing resources, tools
  • issues identified early that can be solved early
  • extensive listing of scenarios
  • elimiation of scope creeping - business user’s gain a comfort level that their needs are understood

 To quote Rod Stewart, “I wish I knew what I know now before.”

Anyone want to add to the list I’d love to hear from you, I can guarantee there are other positive affects from starting early with all teams involved.

Testa