Make Sure Your Project Goals are SMART

Make Sure Your Project Goals are SMART
By David Carr

Previously I talked (typed) about minimising your project documentation so that you can focus your efforts on real communications with your customer and your project team. In the previous post, I mentioned the six key documents that I use to assist me in managing a project. One of the early documents that I create is a list of project goals.

Project goals should be easy to create and easy to document. After all, if nobody, including the project stakeholders, can communicate the project goals then it is time to take a step back and ask if the project is ready to commence.

A useful acronym to remember when defining the goals is SMART. Each letter has various meanings and each should be applied to every defined goal. Here they are:

S – Specific, Significant

Each goal should be as specific as possible and should be clearly understood by anyone with a working knowledge of the project. Rather than saying “Improve the sales process”, how about “Automate sales processing from order taken to manufacture of the custom product”. A goal should also be significant. It is much better to have four or five large goals than hundreds of the ilk, “Copy each order from the web site to the SOP system in less than three seconds”.

M – Measurable

If you define a goal but it is not possible to determine when the goal has been achieved, the goal is meaningless and should be re-worded or dropped completely. Ideally, a goal is measurable to the extent that the progress towards the goal can be expressed at any point in the project. “Make it easy to see the sales orders” is not measurable. “Present the sales orders in the dashboard application” is better.

A – Agreed, Achievable

It is critical that everybody from the customer team and the development team agrees all of the goals. If the customer is in disagreement, achieving a goal will not win you kudos! Goals must be achievable for the reverse reason. Agreeing upon a goal that cannot be achieved is simply inviting project failure.

R – Realistic

Every goal must be realistic. If the goal is not technically feasible or is not within the bounds of the project’s budget or deadlines, do not agree it. Once the goal is on paper, the expectation is that it will be delivered. Unrealistic goals will not be delivered and will lead to the project being deemed to be unsuccessful.

T – Time-Based

Finally, tying the goals to a timescale sets a marker for the project team and the customer. A goal with a reasonable budget of time and a sensible deadline allows the customer to track the progress of the project and understand were a goal generates a large cost. The larger budgets may then be slimmed with a little pragmatism allowing redistribution of budget to other tasks. “Allow automation of the production line using 25 days of budget and completing before December” beats “Allow automation of the production line” every time.

David Carr is a Software Development Manager responsible for team management, project management and software development using Microsoft technologies. This article was reproduced with his permission.