How To Make Things Happen
Some people can apply skills in the combinations necessary to move projects forward, and others cannot, even if they have similar skills. The ability to make things happen is a combination of knowing how to be a catalyst in different situations, and having the courage to do so. This ability to drive is so important to some that it’s used as a litmus test in hiring project managers. Even if leaders can’t precisely define what the ability is without making at least some references to other skills, they do feel that they can sense or measure it in others.
” If after a round of interviews the answer is no, the candidate is sent home. The belief is that if he isn’t agile or flexible enough to adapt his skills and knowledge to the situations at hand, and find ways to drive things forward, then he won’t survive, much less thrive, on a typical project. This chapter is about that ability and the skills and tactics involved.
A large percentage of my time as a PM (project manager) was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I’m convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists.
I collected things that had to be done—requirements, features, bugs, whatever—and put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I’d drive and lead the team as hard as possible to follow things in the defined order.
Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same. I invested so much time in these lists because I knew that having clear priorities was the backbone of progress. Making things happen is dependent on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team.
These priorities have to be reflected in every email you send, question you ask, and meeting you hold. Every programmer and tester should invest energy in the things that will most likely bring about success. Someone has to be dedicated to both figuring out what those things are and driving the team to deliver on them.
What slows progress and wastes the most time on projects is confusion about what the goals are or which things should come before which other things. Many miscommunications and missteps happen because person A assumed one priority (make it faster), and person B assumed another (make it more stable). This is true for programmers, testers, marketers, and entire teams of people. If these conflicts can be avoided, more time can be spent actually progressing toward the project goals. This isn’t to say those debates about priorities shouldn’t happen—they should.
But they should happen early as part of whatever planning process you’re using. If the same arguments keep resurfacing during development, it means people were not effectively convinced of the decision, or they have forgotten the logic and need to be reminded of why those decisions were made. Entertain debates, but start by asking if anything has changed since the plans were made to justify reconsidering the priorities.
If nothing has changed (competitor behavior, new group mission, more/less resources, new major problems), stick to the decision. If there is an ordered list posted up on the wall clarifying for everyone which things have been agreed to be more important than which other things, these arguments end quickly or never even start. Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort.
