Clear Business Goals

This post is in continuation of project success series। We will discuss the point number 3 i.e. clear scope and business objectives.

Any software project, based on it’s outcome falls into 3 categories। 1) Successful, 2) Failed & 3) Hanged project. Hanged projects are the most (in)famous and interesting ones. The beauty of hanged project is the fact that they get’s accepted by customer but still it’s of no use to end user.

Software is developed to meet some business goals and if the goals are not clear and measurable, you will get a hanged software. I would like to mention here the key difference between failed and hanged software; Failed software doesn’t meets software requirements (specifications) and is never accepted by customer, while hanged one meets documented requirements but doesn’t helps reaching business/individual goals.

Individuals either opt to use the software or they are forced to do so; Individual goals makes sense, only when they are inline with business goals of an organization they work for। Complexity begins when individuals start considering these goals as the solution of their functional problems. So we have business goals and business problems and the difference between them is the ability to measure. For example, the “customer wants to increase the production” is a business problem. This business goal is that “customer wants to increase the production by 50%”.

Arnold H. Glasgow says: “In life, as in football, you won't go far unless you know where the goalposts are.” During the software development, it’s important to check and measure the progress towards business goals। The iterative model of agile development helps in this context. I remember the control theory of Feedback Control Systems (taught in B.E, Elec. & Telecom) which defines “feedback” as a process whereby some proportion of the output signal of a system is passed (fed back) to the input. This is often used to control the dynamic behavior of the system. Example is the missile guidance system which measure the position at regular intervals and send it back to control device. The theory fits well in agile development scenario where we take user feedback at regular intervals and adjust the output accordingly.

Coming back to hanged projects; they are derived by specifications that states business problems (most of the times) and not the measurable goals. Though these goals are defined from customer, the project analyst must help transforming business problem statements to measurable goals. This way I believe a customer will have the value for money she has spent to build a software. For us, the software is successful when it’s used by end users and not just delivered and signed off.