Back to TopBack to Top
 

Software Development Lessons for Country Development

 

June 21, 2013

Doug Hadden, VP Products

Gaps between design and implementation are often chasms in software development and country development. Aid and development programs are often criticized because outcomes do not match objectives. My sense is that software development projects, particularly in-house development and ERP customization have similar meagre results. Particularly in government.

This gap can be manifested like a Greek tragedy: professionals use ‘best practices’ and quality standards to prevent failure. Rather than focusing on success. The result: outcomes are murdered.

There is growing evidence that iterative design is critical to country development outcomes. Iteration through agile development have become mainstream. What can aid, Public Financial Management (PFM) and development professionals learn from software development innovations?

Solution Gap

The gap between design and implementation was an underlying theme of the recent Harvard Kennedy School Leaders in Development course led by Matt Andrews. Andrews and his colleagues have shown how Problem-Driven Iterative Adaptation (PDIA) has improved outcomes when compared with traditional country development approaches. PDIA rejects the ‘best practice’ approach – or, what we call in software: ‘solutions in search of a problem.’

The PDIA approach recognizes the difference between complicated technical tasks versus complex projects that touch on multiple government Ministries, laws and face informal barriers to success. Software development may seem like a technical challenge, albeit complicated, but not complex in the PDIA definition. Software development can be of similar complexity because of competing firms, different customer needs, broad ecosystem of partners, incumbent business models and internal company bureaucracy. Many software innovations are quietly killed in companies .

And, failures in software projects are often blamed on people rather than process – just as in country development where failure is attributed to corruption, capacity or political will.

The key to development success, in both cases, is understanding the problem.

And, failures in software projects are often blamed on people rather than process – just as in country development where failure is attributed to corruption, capacity or political will.

The key to development success, in both cases, is understanding the problem.

What software industry processes are applicable to country development?

  • Business requirements (what needs to be achieved) are usually developed separately from product specifications. This means that software company executives typically agree on the business case and success factors before specifying what needs to be implemented. Product managers are responsible for business requirements.
  • The business or marketing requirements focuses on the problem rather than the solution. Each requirement is described as a problem first followed by “conditions of satisfaction” – how we know that the requirement was met.
  • Market requirements must not specify how the software is to be developed unless it is a very important technology industry constraint such as: developed in Java or .Net.
  • Personas and scenarios are used to better understand the goals, behaviour and constraints of stakeholders. This is the first major connection with the stakeholder context. It is particularly important to communicate the context to software engineers who think differently than most people. This is where you are able to shake out so-called “best practice” thinking and focus on something practical.
  • Software development companies typically provide a series of steps between requirements and product coding. The important steps that is relevant to country development is that specifications are typically designed by “business analysts” who have in-depth understanding to the business domain.  These people deal with the details of “what needs to be done” to the software development team who focuses on “how it will be done”. Business analysts are part of the software implementation. (We extend this to on-site implementation of our software where business analysts are communicating customer needs directly to the product development team.)
  • Some companies recognize the difference in skills and incentives among team members in software development. For example, program managers could be responsible for scheduling and rationalizing competing demands. Quality assurance does not report to product development.
  • Agile development methodologies are often used to support iteration – the “I” in “PDIA.” I’m most familiar with Extreme Programming (XP). Like many agile methods, XP deconstructs the specifications stage through the development of “user stories”. These follow a single scenario and must fit on an index card. (Contrast that with full use cases that requires pages and pages.) Development typically occurs in a 3 week cycle giving the software company the ability to prototype work, make adjustment in requirements and better predict when the project will be over. I realize that many people aren’t sold on XP, but I’ve seen significant and important adaptive capabilities.
  • One of the best parts of XP is that status meetings have to be “stand-up meetings” so that people do not get comfortable and start pontificating about unimportant things.
  • Lean processes from the manufacturing world have been adapted to software through the so-called “lean startup”. Many companies develop technology products by using good practices in software design and quality management. The result is a product with few defects that no one will buy because it doesn’t satisfy any needs. In lean, companies developed the Minimal Viable Product (MVP) to test the hypothesis that there is a need. Companies are able to understand what people want by first showing them what they don’t want. This is an important iterative input if the company is using XP.
  • Most companies leverage some elements of agile and lean processes rather than following dogma. It’s best to adapt the processes to the context.

What about Steve Jobs?

“That’s all well and good,” you may say. “But, what about Apple?”

The focus on design by the late Steve Jobs is often seen as an outlier to the state-of-the-art in technology development. Jobs did not iterate with customers.

The important message about Jobs is that he deeply understood the problems of poor usability. He understood the problem associated with computers, smartphones and applications. And, he iterated frequently in Apple. He was the ideal customer to provide feedback.

Few of us can be a “Steve Jobs” in our chosen field. We need to optimize processes to achieve desired goals even when those goals are bit fuzzy when we start out. We can’t claim that country development or software development are art forms that require intuitively brilliant leaders.

The following two tabs change content below.
Doug Hadden

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Leave a Reply