Avoid Starting Out on the Wrong Foot in Software Deployment
There is a Correct Sequence for Software Roll-out or Deployment… Ignore at your own risk.
Sequence is important in lots of areas of life, and each time it tends to bring order and efficiency to potential chaos. The Ready, Aim, Fire sequence is a familiar one, which if followed out of sequence, tends to produce misguided effort and induce more chaos, expense and frustration. Any kid on a baseball diamond this summer can immediately tell if you should choose to run the bases out of sequence, and if near-by will either yell at you or think you’re weird if you do so.
Just like baseball, there’s an important sequence to rolling out software, especially when it is software that will extend across multiple people and impact existing processes (Project management, performance management, balance scorecard and collaboration software are all good examples). Here’s the correct sequence with examples, then let’s explore it briefly.
Software Rollout Sequence:
1. Establish the Goal or targeted Outcome – specifically those goals or standards for which an organization is willing to hold people accountable to reach on a regular basis.
Example – We’re going to coordinate our work effort better and as a consequence reduce out project over-runs by 15% and improve the % of Due Dates we achieve by 35%, all while spending 50% less time in meetings).
2. Identify what changes need to occur in behaviors to reach the targeted outcome, both the new behaviors required, and the old ones that have to be abandoned.
Example – We’re going to manage all projects and tasks that effect multiple people from a central collaborative workspace with clear planning and assignments, and up-to-date information to enable us to achieve our coordination, budget and timeline goals. We’re going to communcate project related information in a timeline specific and brief manner. We’re going to use progress updates and todos or task requests, not email narratives when managing projects. We are no longer going to use whatever we personally prefer as a project management tool (ex. Note pads, email folders, spreadsheets, because yes we all have different preferences) when managing group projects, we are going to use one common tool, so as to sing off the same song book. Finally, we are no longer going to substitute attending long meetings for regular write-ups of updates on projects.
Hint: You’ll have the most success if you think of the required behavior changes as rungs on a ladder, moving from simple (I can do myself) to complex (I can only do with inputs from other systems). Make sure you have all the rungs on the ladder before you have people begin the climb.
3. Roll-out and establish competency and comfort with the new technology – Apply the technology and training in its use to a succession of steps that need to take place to move users from current processes and practices to the new practices that will ensure target or goal outcome in such a way that users build competency and comfort.
Example – The first step might simply mean adopting a common naming convention for projects, a common way of defining the structure and location of projects, how to navigate to the project and view what assignments are due for each user. You would want to start the technology training at that behavior run, not at showing them how to compute estimated versus actual due dates and the relative extension of duration as a % of the entire duration.
Hint: Most people only climb ladders one step at a time, and in a similar fashion, most people learn new technology by building on one new skill at another, not by aborbing lots of new concepts, key strokes and capabilities at once.
Bottom Line: First of all, at the 30,000 foot level, there is a correct 1-2-3 step sequence to rolling out software. In any role out, the new technology needs to support the change in behavior or process, not vice versa. And the change in behavior or process, being clearly defined as needing to support goals for which the organization is willing to hold people accountable to reach on a regular basis. The correct sequence again is:
1. Establish the specific goal or target (addresses one or more pain points)
2. Establish what new behaviors and practices have to be adopted, which ones have to be abandoned
3. Then introduce the software technology to support the new process and ultimately the goal.You can imagine, and have probably lived through, software roll-outs that were conducted out of sequence. They don’t do so well. Obviously, starting with a search for the “right” software is not the first step, even though it’s one that’s commonly adopted, e.g. doing the sequence in reverse order has no positive benefits that we’ve been able to determine. By-the-way, there is some benefit to strategizing about what you decide to target in the behavior and process change sequence. I’ll address that in the next blog.