What Is The Goal

What Is The Goal

Every project requires at least one goal. Most have several goals. Sometimes these are called the project objectives or are collectively referred to as the mission of the project. In fact, we think that the mission of the project is to achieve the goals and objectives. Whatever label is used, defining them clearly and crisply can be one of the simplest and most beneficial things done during the whole software development project. A fuzzy goal will most likely lead to fuzzy results. Managing software projects well is mostly about managing expectations and foreseeing risks.

The software project manager always has at least one goal: to finish the project. This comes from the definition of what a software project is: a unique, temporary effort with defined start and end dates to achieve one or more objectives within the constraints of cost, schedule, and quality performance.

Sometimes, what seems like an obvious software project goal may not be seen the same way by everyone. This is why it is important to write it down and explain it for the project team. For instance, a software development project to build a Web-based timesheet data entry system may be viewed as:

●   An internal tool development effort by the engineering manager;
●   A training exercise by the recently hired programmers;
●   A requirement before starting a new software development project for an external customer by the
     general manager;
●   A marketing tool to demonstrate the capabilities of the development team by the sales staff.

Each of these views implies a different level of robustness, ease of use, and maintainability for the final end-product software deliverable. Unluckily, many project managers would simply state that the project goal is to "build a timesheet data entry system," and leave it at that, inviting misinterpretation later. To clarify the goal for all stakeholders, this project could have the goal and objectives described as in Box 1.

This statement is what some call "the elevator speech". It is a clear but brief description of the project that could be conveyed to the CEO informally on the spur of the moment in a short elevator ride, without prior notice. In the example, it states that the project is for internal use (implying internal benefit but no revenue directly associated with it), it incorporates successful deployment (not just development), it specifies who the customer is (the engineering department), and it cites a time frame (before the beginning of the next major external software product development project).

It is very helpful for the overall goal of the project to be stated in terms that are easily understood and repeated. At any project meeting, anyone on the project team should be able to recite the project goal statement, if asked. This keeps the project focused and may be used as the opening to the "elevator speech" about the project by anyone asked to explain what they are doing to an uninformed observer.

Setting Clear Objectives

In the previous example, the objectives in the goal statement have certain characteristics that make it clear. Most objectives tell what. The best ones also imply why. Good project objectives are:

●   Focused on deliverables, not just processes: The customer ultimately cares about the final end
     product (timesheet system), not the processes needed to get to the end product (SPMP, SRS, etc.).
●   Measurable and testable ($, %, Mkt. Share, Dates): There is something quantifiable to measure and
     test, generally quality-related ("successful" implies that acceptance criteria are defined).
●   Action-oriented: The goal implies actions to achieve (the verbs build and deploy complement the noun
●   Conversational: The goal could be recited and explained in a few seconds (the elevator ride).
●   Doable (within your authority): The goal is reasonable and does not imply trying to solve world
     hunger (many accounting applications like this have been done before).
●   Communicated: The team knows it, and it is published in the project charter (it's also the elevator

Setting clear objectives goes a long way toward starting a successful software project.

When objectives have been set, measurable subobjectives for some or all may be described so that cost and performance may be tracked. Rather than the "big bang" approach of having one or just a few objectives, it is good project practice to set up a number of smaller measurement posts along the way. Many small milestones are better than one big one at the end of the project. The team should have a part in establishing their own objectives and subobjectives. A useful technique for defining clear objectives is the S.M.A.R.T. method. S.M.A.R.T. is comprised of the initials for: specific, measurable, achievable, realistic, and time-bound.

For any objective, determine the specific results and performance targets necessary to meet expectations. Are the objectives specific? Do you and your sponsor/customer both agree on the results required for each of your project's objectives? Are the objectives measurable? How will you know that you are achieving results? What does "meet expectations" mean to you and your customer for each of the objectives? Are the objectives achievable and attainable? Why or why not? What support would you need to attain them? Are the objectives realistic and relevant? Do they address the customer's requirements and real needs? Do they align with the key success factors for the organization, the business goals, and the strategies? Are your objectives time-bound? Are there particular dates by which the objectives should be achieved? Is there a clearly understood reason for each of the dates? What is the driver behind the dates (e.g., your customer's customer needs the product then)?

The following is an example of a (relatively) short-duration objective that is part of a larger quality systems improvement project in a large multinational corporation. Note that it is specific and measurable, achievable for the average corporate quality department, both realistic and relevant to the department and corporation long-term goals, and time-bound (in this case, a specific due date, not a specific duration, as in "within six months from project start").

Benchmark two other companies automated line-manufacturing processes according to ISO 9000 standards. Complete the project by the end of the third quarter at a maximum budget of $30,000.


software project, project team, software deliverable, milestones
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus