In my last post, Controlling Software Deployment, I discussed the process of releasing tasks when the time is ready to execute the steps in the deployment plan. In this post, I talk about the tools we utilized to be able to control the chaos.
From ITIL: The objective of Release and Deployment Management aims to plan, schedule and control the movement of releases to test and live environments. The primary goal of Release Management and Deployment Management is to ensure that the integrity of the live environment is protected and that the correct components are released.
OK- that’s great, but how? ITIL is a good common terminology of what needs to be done, but does not prescribe how the code releases should be accomplished. If I do a google search on “Release Management Tools”, there is a litany of tools that pop-up. The problem is there are so many definitions of what “Release Management” means. Depending on what release means, there seems to be a tool for every situation. A great visual of what that looks like has been developed by Xebia Labs.
Xebia Labs Release Management tools
If you are a project manger trying to determine what is the best for your situation, this is a daunting task at best. Don’t get me wrong – I’ve looked at many of these and they are great products for what they do. The problem that I found is that there was not one that expressly fit our needs. The requirements for our project were:
- Build a single deployment plan: Identify specific tasks with resources, predecessors, successors and estimated durations. This needed to be where we could identify critical path items and dependencies.
- Be able to perform task releases: Keep track what tasks have been completed and identify the next tasks that are ready to be released.
- Real Time Status: The team needed to know and be able to communicate when tasks were scheduled to be released and which tasks were at risk of being behind schedule at any given time during the deployment period.
- Simple: Something that could be assessed and implemented very quickly with minimal ramp up time. The project was already in the final stages and deployment was looming.
- Low Cost / No Cost: As usual, the project was already budgeted and did not have extra money to add a deployment tool.
- Flexible/Configurable: As best practice, process should proceed technology. So we needed a tool that could be configured for our specific deployment process.
The last three seemed to be the nail in the coffin for many of the off the shelf products. There were some that could do the first three rather easily, however, they were either expensive or required time that we did not have to implement. Our solution, was to take a minimalist approach and just use Microsoft Products with a few custom macros.
MS Project: We used the standard MS Project functionality to build the deployment plan with resources, durations, predecessors, and successors. We built the individual tasks using the auto-scheduled functionality which gave us an estimated schedule of how long the deployment would take and would give us warnings if things were slipping behind schedule.
MS Outlook – Since most team members already had outlook, this was the vehicle we used to communicate to resources when it was time to execute the tasks in the plan. We utilized “Tasks” in Outlook to release the individual Project tasks. The resource did not need to have MS Project or have access to the project plan to communicate when the task was accepted and completed. E-mails were utilized to send task notifications to people that needed to be informed when tasks were released.
MS Excel – Project is good for keeping track of the plan, but we needed the flexibility in excel to calculate charts and communicate real time status. Since MS Project licenses are an additional cost to MS Office package, we limited our costs by only giving specific plan owners the MS project license, but reported status to the wider audience in Excel.
VBA vs Project Server: Just a quick discussion on why we chose VBA over MS Project Server. Project Server does the integration with outlook, but there were a few issues with the current version of project server we were on:
- There was only one definition for the custom fields – If one project had defined “Text1” as “Team” and defined it as a lookup field, we could not change that or redefine it for our specific project.
- We could not control when we released tasks to resources. When we sent resources their respective tasks, it sent everything for that resource at one time. We could not send task by task.
- We needed to send specific custom fields and gather information from the task responses – i.e. acceptance/rejected tasks, actual durations, actual completion times
While project server met the requirement to be low cost and simple to install, it dd not meet the flexibility required for our specific project. Instead of utilizing project server, we customized some macros and VBA scripts to automate the release process and provide real-time status.
VBA Links
With any deployment, we needed to minimize the business impact. The time we had for deployment was tight. We had over 300 named resources with over 2500 lines of tasks to complete in 48 hours. Task communication and updates needed to be quick and accurate. To reduce human errors and streamline the task releases, the process we followed was simplistic and straight forward.
Our process was:
- Identify Tasks Ready to Release: We have a code that determines what tasks have been complete and what tasks are ready to be released based on identified predecessors and successors. That task is transformed into an outlook task and an e-mail. The resource is notified to perform the work.
- Accept or Reject Tasks: The resource will accept or reject the task utilizing the Outlook task function. If the task is rejected, outlook will show the task as rejected in the task list. A VBA script in project scans the outlook tasks for these rejected tasks and updates the project plan.
- Complete task and Update Project: Once the task is completed, the resource will mark the outlook task as “complete”. Outlook will show the task as complete. A VBA script in project scans the outlook tasks for completed tasks and automatically updates the project plan with actual duration and actual finish.
- Repeat Process: Once the tasks are updated, we re-run the code to determine the next tasks to be released.
- Provide Real Time Status: During deployment – we have a VBA script to publish the project stats to an excel document. The excel document has pre-defined calculations and graphs. Some of the metrics we display are overdue tasks and when future tasks are expected to be released.