This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
While my co-founders and I were in business school, we saw firsthand how painful and frustrating it is to be involved in the application development process from the business side. So we set out to improve collaboration between IT and the business and to make development radically faster and simpler while ensuring project success.
Here are the seven keys to successful IT/business collaboration.
1. Focus on the business problem, not the customer envisioned solution. The customer’s view of what is possible is often limited by the tools or technology with which they have prior experience. In other words, what they might think is the best way of doing something might not be the best way at all.
It is the responsibility of business engineers — a term we use to refer to non-professional developers who are business savvy, yet have some affinity for technology — to understand the business problem and design the best solution. Business engineers are in a unique position to do so because they possess a deep understanding of the business as well as capabilities of the platform.
One example of a client that was boxed in by previous tools was a large health insurance company. The business problem they were trying to solve was an automated way to collect information from customers. Their envisioned solution was distributing and collecting Excel sheets — simply because they didn’t realize how easy it would be to build a specific web-based interface for customers that are also tied to their existing back-end system. By adding a user role, security rules, and optimized forms, a high-quality interface was built for a fraction of the cost and resulting in a much more scalable and user-friendly solution compared to the Excel alternative.
2. Divide work based on user stories instead of specialties. The latter is a more traditional way of approaching application development, where specific team members each focus on specific technical areas, such as database/data model, UI, etc. This isn’t the most efficient way to work because business engineers can typically complete 80% to 100% of the work themselves, with the exception of some very technical topics (such as styling or integration).
Instead of dividing tasks based on specialties, project work should be divided based on user stories, a term used in scrum or agile development methodologies to refer to a specific feature or piece of functionality written in in the everyday language of the end user (one format is “As a <role>, I want <goal/desire> so that <benefit>.”). These stories should be developed by one or more business engineers as a whole. This way, every business engineer develops a full working piece of functionality each sprint rather than working on a certain activity. In the process, they’re able to better focus on the business solution (see point #1) and deliver the best solution, versus simply completing his/her assigned task. The result is better software and happier end users.
We often see new partners or customers try to divide tasks this old way because it’s how they’ve always worked — and as we all know, old habits die hard. One of our outsourcing partners took this approach early on and the initial progress was less than anticipated. The knowledge transfer and documentation required between different tasks created a lot of overhead and noise, which resulted in low productivity and lack of business agility. Once each business engineer took full ownership of a user story within a certain domain, we saw a dramatic increase in productivity and quality. In addition, the knowledge and understanding of functional aspects of the application increased significantly, resulting in better collaboration and working software.
3. Provide working demos or prototypes every sprint. Systems design can be a very abstract exercise. Two people can literally sit in the same room for hours and think they’re talking about the same thing, but in reality be on completely different pages. That’s why it’s crucial to show working functionality (whether a demo or prototype) during each sprint. The demo/prototype should be used to validate requirements and assumptions (knowingly or unknowingly made) to discuss possible changes because needs or other factors have changed. Changes can even be implemented during or at the end of the meeting to show the business stakeholder what impact it will have.
This process of validating major assumptions by showing working functionality is especially crucial in the early stage of the project. The longer you wait to validate business requirements, the greater the potential disconnect and the more time and effort you’ll need to course correct.
At a large project for a church with 2,000,000 members, the functional requirements for a new application were specified by the church’s volunteers. As soon as business engineers implemented the flow for moving a person to another address, the volunteers asked, “How do we move the whole family at once?” This important feedback highlighted the fact that the concept of families was not addressed properly in the functional requirements. By providing the prototype, the missing requirements were identified within two weeks and the client was able to take the necessary measures to embed into the system.
4. Implement daily “walk-in” hours to validate assumptions and synchronize with the business. There is technology that enables you to rapidly develop new applications and functionality. No matter how precise the upfront requirements are, there will inevitably be points where requirements conflict or business engineers don’t understand something, have questions, or envision a different way of doing something. If that’s the case, they may start to make assumptions that end up needing to be reworked or thrown away altogether.
Therefore, it’s important to ensure there’s an opportunity each day for developers to interact with the business, discuss ideas, and validate assumptions. This may be perceived as a strain on the business but in practice it’s not. When the developer works on site, this can be done quickly during lunch or a break. In other words, it can be fit into the schedule of the business user, creating little to no burden or disruption. And that quick check will save rework down the road.
We’ve found that when their input is put immediately into the product, business users become more much motivated and enthusiastic. They realize it’s worth the time and effort and they start to make a mental business case for themselves to spend time with the developers. Very often, the change in demeanor is apparent from one meeting to the next. By the second or third meeting, they’ve gone from reluctant participants to willing and enthused advocates.
5. Model complex business rules and forms together with the business. There may be times when daily “walk-in” hours are not sufficient, and closer collaboration and knowledge sharing between developers and business users is needed. In these instances, there is technology that is ideally suited to facilitate cross-functional pair programming where business users — instead of the traditional process of writing requirements documents — are paired with business engineers to co-develop complex business rules and forms.
If you think about it, it’s nearly impossible to envision every possible situation or scenario up front. Therefore, once an application or piece of functionality is developed using traditional methods, you have to validate whether the developer understood the requirements correctly, which results in a large and lengthy testing procedure.
This can be avoided by the business engineer and business user modeling the application together. While one-off sessions are a great starting point, many customers take it to the next level by physically locating the development team in the business for the duration of the project, facilitating continuous conversation and collaboration. The business engineer can stop and ask questions about different scenarios, helping to identify and resolve any misunderstandings or issues on the spot versus waiting weeks or months until the application is already built. This way of working enables your team to build the right product faster.
A great example is a pharmaceutical company that developed a site monitoring application as part of its clinical trial process. Because the company’s process was so unique, extensive interaction with the business was required. Therefore, the development team sat with the business and directly collaborated with the business owner to build the application, with no detailed specifications up front. The application was delivered in a fraction of the time and cost compared to the alternative: an off-the-shelf clinical trial management system (CTMS) that would have given them exactly what the competition had.
6. Close collaboration with end user testers (during UAT). User acceptance testing (UAT) is typically a last but important phase of the development cycle. While something might work from a technical perspective, there’s no guarantee it will “work” from a business perspective so UAT serves as the final validation by the business. Traditionally, though, UAT is a formal procedure with a large amount of overhead, such as creating tickets, planning them for release, etc.
UAT assessments can be made on the spot without following a formal, time-consuming procedure. By collaborating closely with the end user test team, business engineers can identify and fix small issues immediately on the fly. Changes are typically implemented so fast that the test team is often able to test the fixed application/functionality before they would have even been able to create a ticket. This approach simplifies and improves the progress of bug fixing and testing in general with better feedback from, and experience for, the end-user.
7. Implement a feedback loop to capture end-user feedback. The number of end users is always bigger than the project team you’re working with (including the business representatives). Therefore, it’s important to facilitate end user feedback to identify those details or issues which are not known within the smaller group responsible for building the software.
The challenge is that traditionally, there have been large barriers to providing feedback: complex ticketing systems, unwieldy spreadsheets, or e-mails that end up in a black hole. In addition, it’s often difficult for end users to explain exactly what they were doing and what they expected from the application. Meanwhile, feedback like “it doesn’t work properly” is useless for developers who require all sorts of follow-up contextual questions.
There is technology that helps to solve these issues by including a feedback button in every application. With a simple click, end users can provide feedback, automatically capturing the context (which user, browser, form, etc.) and including it with the user story that’s submitted to the development team. It’s all part of the same platform – no additional system, process or implementation required – so user feedback immediately ends up with the relevant development team and can be easily reviewed and addressed.
Let’s face it: the perception of the quality of the software is largely related to minor semantic elements: the sequence of input fields, proper captions, etc. Because these changes take minutes to implement and deploy, they are quick wins that can help you to get more value from the software while making end users more enthusiastic.
Despite all of the discussion, there is still a clear disconnect between IT and the business. According to the IT Governance Institute, 50% of organizations lack any formal structure to align IT investments with business strategy. Meanwhile, a CIO Magazine survey reveals that 71% of projects fail because of poor business requirements management.
It’s time to make IT/business collaboration happen instead of just talking about it and experiencing yet another project failure. By embracing the seven principles above, applications deliver faster, cheaper, and with more successful outcomes.