Making Changes vs. Making Do
It’s part of the American mindset to deal with imperfect circumstances; we applaud improvisation.
We cheer when someone makes something out of nothing. We rank the overachiever who overcame every obstacle higher than the perfectly prepared professional.
Remember the story of Apollo 13? We’ve made a folktale out of how engineers figured out how to get a round air filter into a square filter receptacle.
On the other hand, we also celebrate people who take a principled stand. If the plane won’t fly, we expect someone to take that unpopular position, no matter how many dignitaries are in attendance to watch the test flight.
So where do we go as project leaders?
So Which Approach is Better?
A friend of mine who had been in the Army told me a story about being on maneuvers in West Germany. Americans were in awe of the German trucks: They were in beautiful shape, perfectly engineered and awesomely maintained. And the Germans? Were they proud of their trucks? Well, they were, but they were also in awe of the American trucks: They were models of the American frontier spirit of using anything available to get things done.
The fact is, we should admire both. We should appreciate the perfectly prepared project with ample resources, delivering with machine-like efficiency. We should equally admire the strapped-for-resources project, hampered in every way, that manages to deliver against all odds. Neither is morally superior.
What you have to realize as a project manager is that you won’t always get what you want. You’ll have to make do, and encourage your team to work through the disappointment and anger they may feel about it.
However, you shouldn’t feel that you can never make a change or ask for something different. In fact, it’s your duty to suggest the changes, incremental or radical, that you think the project needs for success. You need to be able to identify the absolutely critical thing that’s needed, and plant your flag on it.
To use the military metaphor, that’s the hill you’ll want to die on.
When to Make Change vs. Making Do
In a particular project in my experience, the project was already in rescue mode when I got to it. I tried to help it limp along. That was me making do, trying to use the minimal resources to accomplish the objective. After a number of weeks, however, I identified some key ingredients that were missing: The project team had no documented requirements. We’d pretend we were close to being finished, but in fact, we had no idea.
It was a mess. Time to start over.
Given that situation, the team had the wrong resources – and an item to take a stand on.
This was a good experience, but I hadn’t gone far enough. I was still letting myself be blocked in by certain expectations.
The schedule was the worst part of it; everyone insisted that the project had to have a new schedule. Communications to clients would be based on it, after all. I dutifully built a schedule, even though nobody else would support it. Nobody believed in it. I didn’t believe in it myself.
Since I didn’t know what would happen if I was honest about the schedule, I swore we could do it.
Here’s a tip: If you’re the only person on a project saying something can be done, and even you have doubts, you’re probably better off being honest about the situation.
Not only did I need to change the project team and its work approach, but I should also have forced a change in the need for a schedule. We should have looked for some way to move the project forward incrementally, not letting it get out of control, even though we couldn’t be sure when it would be complete. Years later and with more training and experience, I know I should have proposed an approach based on an iterative methodology like Agile or Scrum – and that that shouldn’t have been the end of the changes I proposed.
As project leaders, we’ll often be asked to use the scope and work plan we’ve been handed, using the team that’s been assembled, and makes the best of the situation. But we shouldn’t settle for that until we’ve explored every avenue of possible improvement.