A successful software project isn’t just about delivering the goods on time and to budget – it is about ensuring the development delivers on the business objectives. And there is the first stumbling block: far too few companies take the time to define those expectations and requirements up front.
It is only with a clear business vision that the company can then move forward and implement the communication, collaboration and cultural change required to deliver both software and business success, explains Zoe Cunningham, CEO, Softwire.
Define Expectations
What is the secret to software development success? The answer is most certainly not any specific technology or methodology. It is not influenced by the decision to adopt Agile or Waterfall; or the choice of .NET over Java. The biggest difference between software project success and failure is cultural attitude and commitment to change – yet this is one area that is persistently and consistently overlooked by far too many organisations.
The problem is that a new software development, whether it is an enterprise application or website redesign, can become very complex, very quickly. Software development has infinite possibilities – given the time and resources it is possible to meet pretty much any business demand. But therein lies the problem: if the essential goal of the project is not defined and locked down up front, project creep is virtually inevitable. Without a very clear picture of the end goal, the business can get distracted. The result is constant change, project over run, disruption and spiralling costs.
Clearly defining requirements up front should be software development 101. But far too many organisations simply fail to recognise the amount of work required to understand objectives. What is the business trying to achieve? What is the end goal of this investment? Without a clear idea, how can the organisation communicate the reason for the change to the business?
Managing Change
Once the project’s requirements have been defined – and signed off by those in charge of the P&L – it is then essential to nominate a product owner. This individual is then responsible for overseeing the development, for ensuring the defined business objectives are not lost and for making the tough decisions.
Different parts of a development will likely affect others, adding to the complexity – the decisions made in one area will influence what is possible in another. A single person responsible for thinking through this complexity, as well as liaising with users and potential users about what they want and what works with them, is essential to keep the project focused and on track. This role can be handled full or part time, depending on project and company size; or it could be outsourced to a third party. The key is to ensure someone has both complete visibility over the project and the ability to make tough, quick decisions.
And when it comes to decision making, look at the chain of command before the project starts and address any potential blocks which could result in project delay. Again, the foundation for this effective decision making is the shared business goal. When everyone involved understands and is committed to the project’s objectives, there is far less risk of bottlenecks and delays caused by multiple tiers of management sign off at every stage.
Communicate, communicate, communicate
One of the most important aspects of the product owner’s role is communication and cultural change. Change will not come free with the technology: the business must ensure that someone in the organisation is responsible for managing change within the business and creating the right environment for the new software to succeed.
User adoption can often be a major stumbling block in any new development – but getting people involved and excited about the development up front will make the eventual implementation job much, much easier. Human beings will always respond well to being involved in decision making, rather than having a decision imposed upon them; starting the process of cultural change at the beginning of the project will have a huge impact on overall success.
There is, of course, a difference between sending out emails about a forthcoming software change and actively engaging with the user base. Nor does ‘user engagement’ simply mean asking users what they want in a solution – that is not a route to success. End users are not technical specialists, they don’t know what is possible and it is not their job to come up with a software design. Ask a user and the response will typically be ‘the same, but better’. So what is the best method?
Open and Honest
Successful communication takes a different approach; it leverages techniques that tease out users’ real needs and their responses to potential change. For example, software can be used to mock up the potential new system, with clickable links that allow users to demonstrate how they respond to a specific design. Getting users to experience potential systems and provide their feedback is a great way to demonstrate their value to the project and to build that important engagement right at the beginning.
Of course, even the best run projects can hit a hurdle or two – which is why communication must flow in all directions and be supported by a culture of openness. At any stage, individuals need to have the confidence to raise concerns: hiding your head in the sand and hoping everything will be ok is a fast track to project disaster. And that can be tough: if things are going wrong, the deadline is tight, there is no scope for change, no additional resources and no contingency, it can be difficult to own up. But the better able the project members are to raise concerns, the sooner they can be addressed. A lack of open communication can only lead to more problems.
And don’t forget to celebrate success. The more the business embraces a positive mindset, the easier it will become to embed cultural change and turn something that is potentially uncertain and difficult into something that is embraced by the company as the foundation of business growth.
