My high school physics teacher was an unforgettable character. A tall, gangly, ex-military man, his enthusiasm for the topic was contagious. As we learned techniques for solving equations or committed key information to memory (like Avogadro’s number) he would ceremoniously announce that we should put these things in our Bag of Tricks for later use. Over the course of the year, I came to believe I actually owned a Bag of Tricks and could manage its contents as I saw fit.
Many years later, Avogadro’s number has found its way to the bottom of my bag, because I’ve spent the intervening years filling my Bag of Tricks with lessons learned for managing projects successfully. Here are 3 of my favorites:
In the normal course of events, I agree with the wisdom that encourages one to enjoy the journey on the way to the destination. Software projects are different though. Projects emerge from a business case, a clear objective to be reached by leveraging a new software tool. The tool, combined with proper change management, training, and user adoption, is intended to facilitate improvements in the way a corporation conducts business.
The ‘journey’ therefore is intended to be as short and sweet as possible; and the emphasis should always be on the destination or outcome. While this seems obvious, it is a harder line to tow than it might appear. Legions of software projects fail or become protracted, expensive, and painful because this concept is not at the forefront.
Projects that become winding roads, like window shoppers aimlessly traipsing through a maze of stores, have lost the plot and are at risk of becoming ineffectual. Project managers must be the leaders in gracefully guiding the direction forward in the face of multiple distractions. Be vigilant about the degree of change that can reasonably be absorbed while still making forward progress toward the business objective.
Managers, project managers or otherwise, tend to adopt and hone a management style over time. This isn’t all bad, of course. But if management styles are immutable then they have limited scope.
Be flexible enough to assess each situation on its own merits and determine what strategy and approach have the highest likelihood of leading to a successful project. This doesn’t mean abandoning necessary documentation practices or procedures just to please the personalities on a team – that structure is in place for a reason; but find where adjustments can be made that can yield substantial payback. Insisting that everyone play the game the way you want or the way that worked before is ultimately not a winning formula.
The planning exercise cannot be underrated as the single most important step in a successful software project; and yet it is often shortchanged for other activities. The initial planning phase should be detailed and should include conversations with all interested parties. Some project managers make the mistake of keeping the planning process as a solo activity that is completed in a vacuum and then unveiled to the other participants.
Another common mistake is producing an overly optimistic plan that shows completion by the desired date, rather than the realistic date. Make sure your project plans include time for unexpected items such as third party delays, technical complications, changes in requirements, illness, vacation, and just general life. A well thought out plan isn’t based on the perfect scenario. Include some leeway and then work diligently to make things successful within the allotted time.
So, what are some of your tricks of the trade or lessons learned? Share them in our comments section below.