Within the current economic environment, companies’ technology projects need to be closely monitored.  New technology is introduced daily and nothing excites technologist more than new COOL stuff.  Mobile devices, tablets, geolocation technology, Social Networking, etc., are all great technology that can help any company compete in today’s world.  But they can also be very costly if they are implemented for the sake of having technology and have no real business plan for using it.  Make sure you have a business need and then find the best technology to fit that need.   Do not find the best technology and then see how it can fit into the business.

Technology projects are infamous for not being delivered on time.   The reasons for this vary greatly, but the one thing in common is the lack of a well thought-out plan.  A common planning method is when an executive sees something he likes and decides he wants it by end of next month.  Then there is project when IT meets with a user; discuss what is wanted; then the IT group locks themselves away for a few months to develop. Later the finished product is handed over to the user.  Projects of this sort are often defined as “you delivered what I said, but not what I need”.  Another common issue is when the project definition constantly changes; someone wants to add a new feature; they forgot to mention needed functionality or they just changed their mind.  This type of scope creep could often lead to a complete redesign. 

There are many different project methodologies around with varying degrees of complexity.  What is most important is that a project methodology is defined and followed.  They should be followed for small and large projects; the only difference should be how much detail is included.  All project methodologies should have some basic components.
It all starts with a requirements definition.  The requirements definition should clearly identify what the outcome should be, who is affected, what resources will be available, and identify any budget constraints. It is sometimes just as important to identify was is out of scope in the requirements definition.  Notice I did not say anything about how long the project will take.  Timeframe should not be determined until you have a requirements definition and a project plan that everyone agrees on.  The more time spent in definition, the easier the rest of the project will be.

A project committee should be established.  Some of the key committee members should include an executive sponsor, project manager, representation from end users, IT personnel, and any other key stake holders.  The committee should meet on a regular basis and have the authority to make decisions that are critical to project completion.  In a perfect world, once requirements have been agreed upon, there should be no changes to the scope of the project.  Reality is that the scope will change and someone needs to assess the impact of the change.  This is a key role of the project committee.  If something needs to change the scope, the committee should decide if the change brings enough value to the project to change the timeframe.  This helps guard against scope creep.  The project committee may decide to defer the change to a future release and not impact the project schedule.

A project plan can come in many forms and should be managed by the project manager.   The project plan is the roadmap of tasks that need to occur to accomplish what was defined in the project definition.   Each task should have who is responsible and how long it should take to complete the task.  It is a good idea to identify what tasks are dependent on other tasks to be completed.  It is important to identify key milestones within the project that will help gauge if the project is on schedule.  Some key items that are often left out of the project plan are: testing, bug fixing, retesting, training, and a rollout plan.  The project manager is not only responsible for developing the plan, the project manager needs to make sure all involved in the plan agree on the plan.  The personnel that are assigned to the task need to know they are making a commitment to complete the task.  Not until the project plan is completed should an estimated completion date be discussed.

The project manager should also use some tool to help log and report issues that come-up during the project.  This is especially important during the testing phase of the project.  This log should state the issue, the date it was reported, who is assigned to resolve it, and date the issue was resolved.  It may be important to add additional information like the criticality of the issue, additional comments on the issue, and potential work-around.  The issues log along with the project plan updates should be shared with the project committee to help gauge progress.

Depending on the size of your organization and the nature of your business, the project methodology may need to include change control process, disaster recovery impact, or other standard processes.   This does not cover everything that may need to be in your project methodology, but they are components that should be included.

Now the hard part is completed and fun starts.  The plan is worked and now it is time to work the plan. The more time you spend on requirements definition and project planning, the more likely you will be on delivering a project on time.