Does completing the deliverables, on time and within budget, necessarily mean the Software Development Project Plan was successful? In other words, does the development team simply need to complete a list of requirements or do they have a responsibility for deliverables meeting the client’s larger project objectives? Every stakeholder has a different perspective but each will be trying to strike a balance in their own cost/benefit puzzle. The problem is that no two stakeholders evaluate the cost/benefit ratio in quite the same way.
Software Development Project Plan and Scope:
In any given project various stakeholders enumerate their needs and expectations. From that, and by consensus, they develop their project specifications. “Consensus” sounds like a good idea until you factor in the assumptions and anomalies created by the differing perspectives of the stakeholders themselves.
Software developers are given the scope/time/budget requirements at the beginning of the project … and that would be fine, if that was really all that was required to achieve the client’s larger project objectives. But bureaucracy can play a part, wherein sponsors and senior managers will sometimes insist on approvals and functionality that does not address any real-world need, creating additional but unnecessary expense.
Software Development Project Structuring:
Project goals, market conditions, and budgetary considerations have all been known to change significantly during the software development project process, making “structure” a rather fluid concept. So I always recommend scoping out a set of “visionary” project options. It is a simple concept that is both predictive and adaptive, providing the client with potential alternative uses for development building blocks that have already been built.
I feel strongly that project “non-objectives” should be addressed too. Non-objectives can be defined as the “assumptions of deliverables” not directly related to the overall project goals. Why is this important? You would be amazed at how many stakeholders have assumed certain things to be inherently included.
Finally, the planning of every project must include an “exit strategy”. Not just how your commitment ends if all goes well, but how your commitment ends if everything falls apart. For example; what if a client’s budgetary issues require them to abandon the project? What if it becomes clear the project has no hope of providing the expected benefits?
Software Development Project Success:
Even if the software developer meets every scope/time/budget requirement … project success will always be a subjective term based entirely on stakeholder perspective. The question is … do you want to change your perspective, as the developer, from “did I meet all project requirements” to “did I deliver the client’s expected benefit”? Making it personal (or not) is entirely up to you!
Software Development Project Criteria:
Evaluating success is a matter of deciding on your measurement criteria related to each of the following categories:
1. Understanding the clients true business needs.
2. Translating those needs into project parameters, objectives, and eventually into technical specs.
3. Building the software application.
4. Monitoring progress and feedback.
5. Redefining functionality as needed.
6. Completing the Project.
7. Implementing an Exit Strategy.
In the end, your evaluations need to strike a balance in the cost/benefit ratio too … but from three different perspectives … yours, the clients, and from the “value-added” aspect. Where the value-added aspect becomes the gauge by which most clients measure the value “you“ added.
How do you define success in a Software Development Project?
