Blog
A Developer’s Perspective on the Importance of Business Focus

Business executives often view software developers as the strange, but necessary, creatures that create the code that makes the business run well – or not.  It’s true that the average developer’s personality is radically different from that of a top salesman.  There’s one thing they have in common:  The need for feedback.  Continuous, constructive feedback can make the difference between an application that delivers great business value and one that everyone hates.

As software developers, we’ve all been there.  After months of hard work, our system is almost ready for release.  We’ve been developing APIs and front-ends, and writing tests.  We’ve been load testing and performing security audits.  And now that we are almost ready for release, our stakeholders are actually paying proper attention to what we are doing, providing the level of business focus that we’ve been asking for since the project started.

Unfortunately, our stakeholders have realized that what they actually want is not what the system does.  There are fundamental changes that need to be made. We can either try to add a series of kludges that will work in most but not all cases, or we can do some serious refactoring. The refactoring option will push out the schedule, blow the project budget, and cause the business to delay key initiatives that were promised to the market and shareholders.  Either way, someone is not going to be happy.  If only our stakeholders had provided more up front input and applied more business focus over the course of the project, we wouldn’t be in this mess.

I’ve been involved in dozens of software development projects both as a technical leader and software developer.  While the common wisdom is that development teams go dark on the stakeholders, most of the time, the development team has been extremely communicative, asking for clarifications, surfacing new ideas and approaches, and keeping stakeholders apprised of their progress. It’s usually the stakeholders that go dark, leaving developers to do their best in the face of looming deadlines.

In reality, business stakeholders and developers need to meet in the middle in order to gain the right level of focus and deliver business value.  Your stakeholders shoulder many responsibilities besides defining the feature set and performance characteristics of a software application.  Often it takes a deadline such as, “We’re releasing in 1 month,” to capture the attention of the stakeholders.  Unfortunately, this creates a situation that is not conducive to a successful release.

Creating the Ideal Stakeholder – Developer Relationship

Here’s a look at the difference between an ideal approach to gaining business focus and the most common approach:

Ideal scenario Real world scenario
The business has a full understanding of their existing systems and processes.  The business knows what data exists and understands the problems with this data. Existing systems have been developed piecemeal and no one knows what all the systems do (Ten Mile Square’s Continuous Delivery Practice can help with this).
The project team is given enough time with the stakeholders across the lifespan of the project to understand what the stakeholders really need out of the system.  Plus, there is an easy way to clarify requirements when ambiguities become apparent. The stakeholders are busy.  The team gets to interview some stakeholders but not as much as necessary.
Once development starts, there is a single primary stakeholder (Product Owner) who has the power to make requirements decisions and who keeps in close contact with the development team. Multiple stakeholders all with different schedules.  It’s very difficult to get them to agree on anything in a timely fashion.
Feature creep and changes are managed (There’s no such thing as a project without feature creep). Stakeholders don’t take the time to prioritize.  Everything is equally important.  No one remembers features/resources/time discussion that occurred at the beginning of the project.
Business makes time to test the system as internal releases are delivered and provides feedback in a timely manner. Internal releases occur regularly but business doesn’t have time to look at them.

 

The Six Rules for Driving Business Focus in Development Projects

A successful technology project requires the stakeholders just as much as the technology team.  Even with amazing software engineers working for you, without business focus, you risk ending up with a product that doesn’t do what you need it to.  Here are the six rules for ensuring that your company applies the right amount of business focus to a development project:

  1. Delivery cycles need to match business capability. The features/resources/time tradeoff applies to stakeholders as well as the technology team.  When your business is developing a technology plan, limit the rate of system development based on the amount of time the stakeholders will be able to devote.
  2. Make sure the project team has access to the right stakeholders. Requirements changes often come from those stakeholders that weren’t involved at the start of the project.
  3. Embrace change, but in a controlled manner. Nowadays, many development projects use agile methodologies and teams can adapt easily to changing requirements, but that doesn’t help unless requirements changes are communicated to the project team.  Make sure your stakeholders revisit requirements periodically over the course of a project so that necessary changes can be identified and communicated to the team.
  4. Assign a Product Owner or Project Manager who is responsible for the requirements. For any project with more than two developers, designate a project manager who is responsible for continually verifying that requirements are correct.  In some cases, the project manager can be one of the developers, but it most cases, it can’t because too many context switches decreases developer productivity.
  5. Make acceptance testing easy. Ensure that the project team makes it easy for the business to perform user acceptance testing of the internal deployments.  The harder it is to test, the less time the stakeholders will spend testing and the less feedback you’ll get.
  6. Communicate constantly in ways that are easy for stakeholders to digest. Find an easy and transparent way to keep stakeholders in the know. Surface problems early and get the right feedback to solve things quickly and stay on schedule.

A Word on Ten Mile Square

Ten Mile Square has extensive experience with technology planning and full life-cycle software development.  When you’re ready to start thinking about your next development project, we can help you identify the right amount of business focus that you’ll need to ensure a successful release.

Categories: Architecture, Blog, BusTech, Product Management, Software Development, Virtual CTO

Jay Gelman
28 Aug, 2015


Leave a Reply

Your email address will not be published. Required fields are marked *