Software Development Dilemmas Solved


Research to Practice • Practice to Research

Software Development Dilemmas Solved

Posted on October 23, 2014

0 comments 1655 Views

By Jeff Denton

Amid the recent news of failed systems and software crashes taking its toll on nerves and patience across the country, there can develop a distinct lack of trust – or even fear - of working with programmers and software developers. Almost 30% of large software projects (projects with budgets greater than $1M) fail.  Why so many projects fail is a matter of endless analysis and debate; however, a few reasons consistently surface. Lack of communication among stakeholders, insufficient planning, and poor team/project management lead to the budget busts, poor quality, and late deliverables that are the hallmarks of software failure.

TRI-TIMS (Technology and Information Management Services) has a 13-year track record of delivering quality software on time and on budget to Oregon state agencies and national non-profits. As the bad news of failures hit, we took the time to examine what characteristics of the TIMS workflow has lead to our successes, and what obstacles and threats we have learned to avoid.

What came out of that exploration is a framework of best practices that we found can put a project – and keep a project -- on track. Below are the 3 essentials for working with software developers that we believe can move your work forward without busting the budget or costing you sleep.

Work small

Work small

Evidence indicates that the larger a software project is, the more likely it is to fail.  There are many reasons for this but the primary one tends to be scope and feature creep.  Large projects often have dozens of stakeholders, many of whom have competing interests and needs. This dynamic can introduce extreme complexity into a project, delaying timelines and causing instability in the final product.

When beginning a new project, a development team should invest a lot of time identifying and understanding the core features. Build and test these features first; the “bells and whistles” can always be added later once everyone involved agrees that the core features are in place and working.

So, what exactly does “small” mean?  TIMS software projects typically have budgets of less than $500,000, time frames of less than 18 months, and a team of 5 - 7 including 2 programmers, 2 - 3 data analysts, and a project manager. Over time we have found that projects of this size match our development capacity well. The capacity of your developer may allow for much larger projects than this - the point is, know their capacity and only entertain projects that are a good match.

Maintain close communication with all project stakeholders

Maintain communication

As a general rule, smaller projects have fewer stakeholders. Our projects usually involve no more than 10 stakeholders total, including client staff, programmers, data analysts, and project management staff. With teams of this size, communication can be fast and transparent.  Technical staff can be involved from the very start when requirements, scope, and feature set are being decided.  As the project moves forward, we believe clients should have direct access to technical staff, if need be, without going through layers of project management first.  This helps to ensure that client needs are clear to the people who build the finished product.

Stick with who and what you know

Stick with who you know

A quick read of TRI’s mission statement shows that our primary clientele are education and human services agencies.  We understand well the needs and challenges inherent in these domains and we rarely stray too far from them.  In other words, we probably won’t build an e-commerce platform, a project management application, or a social networking site.

Find a software developer who has the core competencies and domain expertise you need. It’s tempting to believe that a software solution built for one industry or problem domain can be “tweaked” into a solution for another.  But as you begin to apply a known solution to an unknown domain, you can very quickly discover unanticipated needs and requirements that drive up project cost.

Likewise, ask if the developer will be contracting out any of the work, and if so, will they be using people who have helped them achieve success in the past. TRI has traditionally had only 1 full-time software developer on staff so we often need help when tackling larger projects.  To date we’ve worked exclusively with 2 individual contractors to get the majority of our software projects completed. We know absolutely that these professionals can deliver high quality software that matches the needs of our projects.  If a project is behind schedule, it is not a good idea to ask the developer to quickly increase their team size with unknown developers.  Doing so invariably increases complexity, disrupts team dynamics, and causes further project delays. It is better to ask the developer to reevaluate the timeline and provide you with a more realistic estimate of time and cost.

Custom software projects can succeed and the build process can be rewarding and even enjoyable.  Keeping project scope at a comfortable level, finding a company that sticks with their core competencies and familiar developers, and promoting quick and clear communication among stakeholders will greatly increase the likelihood of your project success.


0 Comments

We value your comments

Let us know that you are a human.
What does the 'R' stand for in TRI?

The Research Institute : Western Oregon University : 345 N. Monmouth Ave. : Monmouth, OR 97361
Contact Us: 800-438-9376 | info@triwou.org