The approach sets a date for final implementation (as in the tool is installed not the adoption form CM uses) and then determines other dates along the project timeline by subtracting. Something that will happen 10 days before the implementation is set at T – 10.
From a project standpoint this helps in a few ways: smaller numbers likely increase urgency, there is a continual emphasis on that monster deadline date, the amount of time for something can be illustrated with numbers (from T- 20 to T – 10) and not only does the beginning and ending get set in stone so do all the parts and pieces.
From a change management standpoint this is a double edged sword: T- minus is actually a morphed form of end state back (kind of ruined with the T minus date), within the project stream this is a helpful way to actually put dates on things, doing so continues to refocus on the end state (or at least the arbitrary day it supposedly starts) and playing the T minus game soothes edgy project managers.
How do you borrow this for change without messing up all your careful pre-work (front loading)?
It is a project management technique.
Keep it there. Help out the PM by putting layered change tasks (training, communication within the project timeline, events, etc.) into the T minus structure. Don’t do any kind of T minus with the overall change work. (although how would a T minus from an imaginary end state date work…). And continue to emphasize the importance of end states and post “implementation” change work.
T Minus timing reveals a lot.
Watch how the PM (or PMO if this is big change) determines these, let’s face it arbitrary, dates. Are they padding the time? Are they favoring in their date range picks certain functions? Does it appear they are making assumptions (perhaps of invisible resistance) in their date pick process? Are they missing spots where the date, from a change perspective, need to be padded (resistance or other)?
What effect does T Minus have on stakeholders?
For a project management organization the setting of T dates usually calms stakeholders (false calm as seen by the CM). For other companies T Minus is a false fire alarm that simply sends everyone into a screaming help mode. For either version helping stakeholders to understand T minus is a project technique not one for longer change processes can make dates helpful. Change is not entirely date-less, even outside the project stream.
Use it if you have to, delay it if you can.
T minus is a good “herding cats” technique to get things going, to force commitment and to monitor date padding. For project managers. Do the best you can to delay the T minus work until the right time. Fill in the pieces for end state descriptions and the change process before timed work takes away the attention to behavior the stakeholders need to start with. If you WERE able to get that front loading in by all means adopt the T minus approach for those tasks you are responsible for. It is a great approach to TASK.
T Minus is a powerful approach to project management timing and push. Change Management is less about push and timing and more about vision and understanding. There are some overlaps that make T Minus an option for some parts of the change process.
