Starting a discovery phase with a client can be a time of trials and tribulations with scope 
creeps and unclear vision. When we work on intranet projects, some clients have very clear pre-set requirements and others expect, us the consultants, to conduct interviews and come up with requirements. Either way, requirements can change during the process and need to be addressed.
Traditional requirements gathering documentation are long and detailed. It typically outlines how the system should work with very limited flexibility for the delivery team during implementation. These documents are used in waterfall projects where a project is executed in a very linear fashion. Requirements are typically defined up front meaning you are stuck with them later.
Instead, there are ways to be effective, efficient and iterate on requirements. In the past few years we have seen an emergence in the terms “agile” “lean” “DevOps” coupled with tools such as Atlassian JIRA, Microsoft TFS, Microsoft VSTS and Microsoft Planner. This article is not going to define these terms, instead it will explain how to transform your clients to adopt these technologies and get rid of old style documentation.
Getting the clients onboard with agile methodologies is tough especially if your project duration is short. If it is long there are lots of opportunities to either bring in a coach or spend time breaking down your activities into sprints by having dedicated sprint planning, daily standups, sprint demos, sprint retrospectives and of course describing the value in being agile to your client. Out of all this, whether you are truly agile or not, whether your project is short or not, you can leverage a robust tool to support your requirements. This helps follow the agile manifesto of “working software over comprehensive documentation”. At Withum Digital, I have been one of the advocates for using Microsoft Visual Studio Team Services (VSTS) on all of my projects whether few month engagements or yearlong engagements.
Before I get into how I made the transformation, let me share with you what VSTS offers 
based on the graphic and example of the tool. VSTS has a Git repository for code where developers can manage and share source code, build and release their solutions and test apps. There is also a customizable dashboard to show trends and status of progress. Where I find most value is the Agile tool where you can plan, track, estimate work, and add bugs in a very easy way.
I showed value to clients that were either using excel sheets, word documents or e-mails to communicate or document requirements to use VSTS. How did I do this?
Let’s take a classic use case of one of my projects where the client had previously used an excel sheet to track all requirements. It was a nightmare to track the work, what changes were being made and prioritizing the work. Everyone from the delivery team to the client did not do a good job planning work and prioritizing.
My main approach was to build trust and confidence mainly because clients are used to application overload in their space (and from consultants), so introducing a new tool in the mix is tough.
By engaging the client from the start, you can get them excited about a creative tool to help productivity and visibility. I imported all requirements into VSTS and provided a demo on all the features. Showing the client that you are organized about the requirements and capturing their requests frequently provides the confidence boost. I found clients became much more engaged in wanting to distribute work out and conduct prioritization activities.
Demoing the tool was the most effective approach. I showed that any updates made to requirements can be shown through a history log. I showed them that user stories can be linked together with bugs if they are dependent on one another to complete the product. Giving them the visibility and advanced tracking is much better than using an old-fashion documentation where you lose historical data.
Setting a clear governance practice on what clients should update versus your team is important. You do not want clients to update any requirements because you will lose track. Instead, you can empower them to add bugs to specific tickets. You do also have security permissions you can use to help manage what the “stakeholder” permission can do providing control over your project.
Overall, this has been a very successful tool for our clients. It helped shift their thinking and confidence in the project. It has helped us to collaborate much more efficiently instead of just talking about status of work. We can have fun and enriching prioritization sessions without looking at old- school documents. Most clients are tired of looking at Word, PowerPoint and Excel in their daily meetings, so it’s engaging to bring a creative solution to the table. Worst case if the client does not want to use the tool, you can still use it internally to plan your work with the delivery team.
Have any questions about adopting Microsoft Visual Studio Team Services or want to learn more about governance? Reach out to us online or give us a call at 240-406-9960.
How Can We Help?