In this article I thought I’d write about something not so technical – Azure DevOps Project Lifecycle. Did you know that Azure DevOps is not just for developers and architects? You can get a lot of benefit from Azure DevOps already during the sales phase of a new project.

Very often when talking about project lifecycle, not just in Azure DevOps, we tend to focus only on Design – Build – Test – Deploy.

But, there’s a lot that happens before you even get to the Design phase. And that is the sales phase. In my experience, companies very often tend to handle the sales phase very much isolated from the actual implementation phases.

But it shouldn’t be that way. And with Azure DevOps it does’t have to be that way either.

Introduction

So what’s the problem I’m trying to solve? To put it short, it’s the complete disconnection between work estimates that you give during the sales phase and the features and functionality that you design and build during a project. I’ve seen this so many times in different companies.

Here is a scenario that I believe is quite common. You can probably recognize at least some of these phases.

1. Request for Proposal
   • A potential customer sends you an RFP for something they want you to build
   • The RFP contains a detailed, prioritized and categorized list of requirements
   • The requirements list is very often an Excel workbook
   • The customer wants you to add your work estimates to the requirements list
2. Proposal
   • Your sales team produces a proposal
   • The sales team asks a potential implementation team to participate in the work estimation
3. Adjustments
   • After the initial proposal, you typically iterate over the requirements with the potential customer
   • Often some features are moved to later phases
   • Requirements are reprioritized and recategorized
   • Work estimates can change based on better insights into customer requirements
4. Implementation
   • In an ideal world the customer would accept your proposal
   • You start the implementation, sometimes with a different team than the one responsible for work estimation
   • During requirements workshops, you add Feature and User Story work items to your backlog
   • The implementation team processes the backlog and adds their work estimates to the work items

At this point, the original requirements list is already quite disconnected from the work that you have planned to start working on. Sometimes the original work estimates that your sales team sold are completely different from what you have planned.

Solving the Problem With Azure DevOps

Did you recognize the situation I described above? Do you think that it may be a problem in your organization too? If so, then I suggest you continue reading.

The solution is actually pretty simple. You just create your Azure DevOps project already before starting to work on your proposal. Then you add all the features and requirements you got from the customer as Feature work items, and add your work estimations using the Effort field. If you want, you can also prioritize the features using the Business Value field.

Then use the Sprints in Azure DevOps to associate the features with different phases. You might also want to map your features to Epic work items. This is especially useful if your customer has categorized the features in the RFP with different business initiatives.

Connecting to Azure DevOps From Excel

To open your Features Work Items in Excel, you need to install the Azure DevOps Office Integration add-on from Microsoft. After that, you need to build a query that returns the Feature work items you want to include in your proposal. The Office Integration add-on adds a Team tab to the Office ribbon in Excel.

All you have to do now is to open the query you created by using the New List button. By default, the Work Items returned by the query will show up like this.

From here on you just need to apply some Excel magic to make your features and work estimates look something like in the pictures below.

These tables and pivot tables are very similar to what you typically have in proposals. In case you need to iterate over the phases, prioritization and even your work estimates, you do that work in Azure DevOps. When you are done, you just hit the Refresh button in Excel, and you have an updated version for your customer right away.

Compared to disconnected tables in a Word document, these present a huge advantage for you. They contain actual Azure DevOps Work Items that your development team will start working one once your proposal is approved. And that means that you have a better chance of delivering your project within the given work estimates. And that will result in happier customers and better profit. Wouldn’t you agree?