Software innovation can be constrained by scope limitations, and the barriers created by artificial silos in existing systems and organizations. But help is at hand. This article looks at two very different approaches — the application of systems engineering, and customer-centric thinking.

Legacy sets limits
In the early days of a software development project, there are visionary ideas, novel approaches, and exciting goals. But the cold light of reality can set in at any moment — available resources and required delivery dates can be defined at a very early stage. The project adapts its thinking to meet these constraints.

Both traditional and agile methods allow the project team to keep faith with their vision, and get on with the ‘core’ (to match the budget and schedule), while recording everything else on the WIBL (Wouldn’t It Be Lovely…) list, which hopefully will feed into some later phase of the project. So the big idea which got things started isn’t lost, it just gets a bit fragmented.

Sometimes there are legacy issue which can be even more of a constraint — database schemas which no one wants to touch, or perceived turf wars, or tough technical mountains.

These issues create even harder constraints than resources and timescale. Project teams adapt their thinking. It’s not easy to think of what should go on the WIBL list. The easiest response is to redefine the project to stay entirely within the scope of control of the project team. The big-idea can suffer.

Systems engineering
Systems engineering got bad press because in the early days it was a documentation-heavy methodology, which fitted a big-budget project and a waterfall approach to development. The systems engineers had to spend up-front time on extensive requirements and systems architecture documents. More “ready-aim-aim-aim-aim-…” than the agile “ready-aim-fire-what have we got-let’s go again” approach.

The early days are over, and systems engineering is back center stage. “Model based systems engineering” (MBSE) replaces documentation with models. Tools can guarantee model consistency. Some models allow component performance estimates to be attached, enabling ‘execution’ of the model to simulate system performance and visualize some aspects of function. This approach fits agile projects.

But in relation to innovation, the key role of systems engineers is in setting scope. As always, it remains the duty of the systems engineer to consider all the relevant domains which impact the system being worked on by the team. Systems engineers must optimize and prioritize requirements from all these domains. Of course, the central domain is the function and performance of this system itself. But, for a systems engineer, the domain of software development processes is also in scope, as are the domains of delivery, provisioning, deployment, operations and maintenance environments for this system.

So the system engineer has a chance to see and articulate the legacy and silo issues which constrain the innovation potential of the project. Of course this does not solve the problem, but at least it brings the issues to the surface for reasoned consideration.

Customer-centric thinking
Let’s assume that the customer for the results of the development project will be a user who pays for the right to use the software. In this case, true customer-centric thinking means that the project team should consider the whole customer experience.

This means checking for gaps in requirements by looking at the whole lifecycle experience for the customer — what will the customer see and do at every stage — discover, investigate, buy, deploy, use, maintain and upgrade the new software? This is quite a long list, especially when we all know that handling just ‘use’ can seem challenging.

So, just like systems engineering, this doesn’t solve the problem. But handling the other steps will probably mean talking to other groups in your own organization. These conversations will help identify the constraints that threaten the big idea. And who knows, your colleagues may find time, budget, resources and perhaps other ways to support the project’s full innovation opportunity.