April 12, 2005
Wish Statements
Businesses are consumed with making their operations as efficient as possible. This is a reasonable thing to assume and expect a business to do. After all the thought goes, if we can accomplish more with the same amount of resources as normal, the company as a whole would be better off . As obviously true as this is, there is a line of thinking that says that this attitude is counter-productive to a company and to projects. I will explore that topic more in a future blog.
Regardless, this efficiency paradigm inevitably finds it way into LIMS projects. Sooner or later, one of the responsible managers of the project will decide to put a stake in the ground, define a date that needs to be met, and announce to the team that the method of making an important deadline date is to have the team do their job better or harder.
In order to demonstrate out-of-the-box thinking and textbook motivation, the manager will challenge the team to success by issuing what I call a "Wish Statement". A wish statement sound something like: "I would like to have all tasks completed by Thursday". This statement does not begin to address whether it is actually possible to complete all tasks by Thursday. I know what these wish statements sound like since I make them and hear them often enough. There is usually a valid reason (at least in the stator's mind) why someone makes a wish statement. The person making it may even really want the outcome.
The problem with wish statements is that wishing for things alone does not produce results. Regardless of what we thought was true as a child, just hoping is never enough to provide reality. In order to change a wish statement into reality, some amount of change on the project must follow. The kind of change that is needed involves more than just having everyone work harder or smarter.
Instead, the best way to turn a wish statement into a reality is to offer the team incentives for completion. For example, a manger could reduce the amount of work in one area of the project in order to gain accomplishments in another. Or a manager could offer to provide reduced workload for a length of time after a hard fought intermediate goal is accomplished. Won't both of these either cause a part of the project to fall behind or non-project operational work to go unattended? Sure it will, but is there really a magical way of producing more work and meet unrealistic deadlines without sacrificing something in return? No, there isn't. Extracting more work from project workers unnecessarily will cause the rest of the project to lose something. A deadline date for an accomplishment has to cause an equal amount of sacrifice from the management as it does from the project team. If the project team sees that they are the only ones sacrificing, then they will no longer sacrifice, or worse, they will leave in the middle of the project. Without thinking about it, project team members understand at a fundamental level that there is only a finite amount of work that can be done and in order for them to focus their time and bear down on completion, something else must suffer. Like a mechanical part that is stressed from two forces, it is inevitable that a team will break unless relief is provided somewhere.
Is this to say that teams shouldn't be asked to make deadlines and workers shouldn't be challenged? Of course not. Deadlines are not only a reality of project work, they are quite vital. They are a sign of what is truly important in a project and are visible from all stakeholder levels. Let deadlines serve their purpose of showing all stakeholders what is important and providing goals and motivation. Just don't expect that wish statements based on desire are going to actually be able to be accomplished without providing the whole team a way of accomplishing them.
Posted by Brian Jack at April 12, 2005 08:56 PM
Trackback Pings
TrackBack URL for this entry:
http://www.jandrconsult.com/cgi-bin/mt/mt-tb.cgi/39