Subscribe via RSS Feed

Author Archive for Cathy.Brunsting

Changing the Conversation on Software Requirements: Collaboration in the IT Team

motion gears -team forceDelivering Business Value is a Team Sport

Last week, I talked about how to change the conversation of better software requirements from creation of the “perfect” requirements documentation to establishing joint accountability between the business stakeholders and the IT team for the success of the project. This week, I want to talk more about how this approach can carry into the detailed phase of the project.

In July I attended my company’s “Tech Talk”.  My company, a software development company called Geneca, regularly holds Tech Talks to give employees the  opportunity to share technology information. Even though I am no longer particularly technical, I like to attend these sessions in order to keep up on the technologies that my peers and the industry are using.  At the last Tech Talk, Chris Johnson (one of the developers) spoke about a high-productivity web framework for Java development. I know – you’re asking “what does this have to do with better requirements”.

What really excited me about Chris’s talk (since I didn’t really understand all of the coding detail) was when he explained that one of the big advantages of using this technology was that he could partner with a Business Analyst (BA) during the requirements process and actually create web prototypes while the business was explaining what they needed.   The business stakeholders could see how the team was envisioning delivering the solution and give immediate feedback. The developers would also get a head start on the code for delivering the solution.

To me, this was an excellent example of how the entire IT team can work collaboratively to deliver true business value. My co-worker wasn’t holding the BA solely accountable for ensuring that we had the correct requirements.  Rather, he was making the conversation about ensuring everyone was accountable for understanding what the business really needs and for delivering business value. And, by working together, all parties (the business stakeholders, the BA and the developers) can better share a common vision of the solution.

Think Beyond the Requirements Document

I have worked in other environments where the BA would have been threatened by the idea that a developer could create a working prototype during requirements definition. By including the developer (or a PM or a tester) in the requirements process, there might be fear that the BA role would be devalued. But, a good BA needs to understand that the role of requirements definition is not just in the realm of the BA. In fact, ownership of the requirements really belongs with the business stakeholders. The role of the BA is to help communicate the business vision to the rest of the team, by whatever means works best.

Rather than focusing on the requirements document as being central to their existence, the BA needs to find the best vehicles for communicating the business vision to the rest of the team and for ensuring that the team works together to deliver what the business expects. This can be through written requirements, through diagrams, or verbal communication. Or it can be by including other team members – the PM, the developers, QA tester – in the requirements process so that entire team understands the vision and is focused on delivering business value.

When everyone on the team is working collaboratively and holding each other accountable to meet the project’s business objectives, then the project will be a success – regardless of whether the requirements documentation is perfect.

How does your IT team insure that they are delivering business value?

Changing the Conversation on Software Requirements: The Role of Business and IT

What, Truly, Is the Role of a Business Analyst?

Arper-Aston-Office-Chair-IncaseRecently I came across the question “is a written [software] requirements document really necessary?” in a Business Analysis forum. I found the question intriguing and had to look at the discussion around the topic. A lot of the discussion revolved around methodologies (Agile vs. Waterfall) or around requirements techniques (diagrams vs. words). One responder claimed that “the creation of the requirements document is central to BA’s business existence.”

I was bothered by this direction of the conversation. To me, if “the creation of the requirements document is central to their business existence” then the Business Analyst (BA) is not focusing on the right way to improve requirements or to ensure project success. To me, what is central to a BA’s existence on IT projects is to focus on ensuring that the team is providing the agreed to business value for the client. Any documentation is simply one method of communicating the business need and what success looks like to the business stakeholders.

Poor requirements or scope creep are often listed as top reasons why projects fail. We’ve all heard statistics, such as, “more than half of all IT project fail to meet the business requirements”. At a recent webinar hosted by Geneca and Forrester Research, the Forrester analyst pointed out that finding and fixing a software problem after delivery is 100x more expensive than finding and fixing it during the requirements or design phase. Obviously there is a need to ensure that the requirements process is successful.

Think Beyond the Documentation

However, is creating “better” documents going to provide this success? Is more and more documentation going to provide this clarity? Is developing the “perfect” template going to solve the problem with requirements? If the focus is only on improving the requirements by creating better documents or providing more documentation, then I believe that the team is missing the root cause of why the requirements need to be improved.

Most of the BAs that I have worked with are competent and create readable documents. Although they work diligently at capturing all the project requirements, projects can still go awry. The business complains that IT isn’t delivering what they asked for. IT complains that the business doesn’t really know what they want. Business stakeholders “sign off” on detailed requirements documents without really understanding their content. Development teams create software without really understanding what it is that they are delivering.

Perhaps what we need to do is to make the conversation about understanding what needs to happen in order to accomplish the goal of providing true business value. To do this, the business stakeholders need to be accountable for defining what is of value to them – defining what success means. And, all of the business stakeholders for a given project need to be aligned on what success for the project means. If the stakeholders don’t have a common vision of what success for the project means, how can IT be expected to deliver a successful solution?

Create Clear Accountability for the Definition of Success

Likewise, IT cannot tell the business what success is. It is not their job to tell the business what they can and cannot have. The IT team needs to be accountable for listening to the business stakeholders, understanding what success is from the business’ perspective and then communicating what it will take to deliver to that vision. IT can offer alternatives and suggestions on ways to deliver to the business’ vision in a timely, cost-efficient way. But, ultimately the business stakeholders own the decision on which alternative to accept. The entire team – both business and IT members – are then jointly accountable for the success of the project.

In this environment, the role of the BA shifts from just being a creator of documents to being accountable for communicating this common vision to the IT team and helping ensure that they provide a solution that meets the business vision. The requirements documentation becomes just one of many vehicles to help accomplish this goal, not the end goal of the role.

What is the expectation for the BA in your organization? Are you expected to be a documents creator or to take a more active role in ensuring that the right solution for the business is delivered?

Next week, we’ll talk about how to carry the common vision throughout the project in order to deliver a solution that truly delivers business value.

Photo Credit: Incase

Beyond Complete: Success is Making a Lasting Positive Impact

What is “success” to you? Imagine yourself working on a project. The project is on-time and on-budget. All of the requirements have been met. But, how successful have you been with the project? Have you made a lasting impact with your customers? Are they eager to work with you on the next project? Are they recommending your work to others?

Reaching the Destination May Require an Unexpected Route

A customer engagement is not just about meeting the common standard measurements of success (on-time, on-budget, etc.), but is about partnering with your customers to predictably deliver what is needed for them to be successful in their business. It is about anticipating what the customer needs. It is about the courage to deliver a difficult message when you discover that the recommended solution is not going to deliver the desired results, even if you fear that you’ll be perceived as having made a mistake. And, it is about being flexible in your approach so you resolve issues instead of worrying about meeting a plan that you know is not working.

One of the most successful projects that I’ve worked on was neither “on-time” nor “on-budget” and the final delivered solution was significantly different than what was requested in the original requirements. Yet, the project was considered a success – the customer was extremely happy with the results and continued to engage with my company and team for additional work.

127385974_4c9b5e3acf_mFulfilling a True Need

What made this project successful?  Our team partnered with the customer to understand what the true needs of the project were. In the middle of the project, we determined that while we could deliver to the original commitments, the solution that the customer would have received would not have met the customer’s needs. Instead of continuing to deliver to the flawed plan, the team alerted the customer to the issues and worked with them to restructure the plan to deliver a solution that better met their needs.

Was the re-planning painful? Of course it was. As more information was uncovered, we actually restructured the project and the sub-teams twice during the project life cycle. So, in addition to keeping the client satisfied, there were also challenges in keeping the team focused and delivering quality. However, the end result was worth the pain in the middle of the project. The final solution delivered the value that the customer needed within the necessary time frame. The team was able to celebrate a successful delivery.

If we had stuck to the original plan, the team could have delivered the project on-time and on-budget. We would have met all the requirements of the project. It is even possible that we could have gotten future work from the customer. However, the customer’s perception of us would have been just another consulting company that they could use for work if needed.

Instead, by not delivering on-time or on-budget, but by predictably delivering value with “no surprises”, we became a trusted advisor to our customer and they became enthusiastic advocates of our company and our people.

What does “no surprises” mean to you? When have you changed the course resulting in a win for all?

Photo Credit: Olivier Bareau