Company Philosophy
Todd's Lessons Learned
People say it is tenacity that makes me good at recovering projects, some say my attention to detail and others just think I have a penchant for headaches, heartburn and working long hours. I am not sure if there is one reason. As for myself, I know I like figuring out how things work and fixing them—be it clocks or cars,printers or projects. After working on a variety of projects that were in a shambles, projects needing someone to put them back together, I have developed a process for fixing projects that also shows how their problems can be prevented in the first place.
I did not set this as a goal in my life. The goal came after me. Bosses or cohorts would call about a project in need of serious attention—it was behind schedule, losing money, the customer was unhappy or some combination of all three. Many times the conversation would start with "How current is your passport?" Soon I was on an airplane. Upon arrival, I would start by going through contracts and deliverables, talking to everyone on the project trying to understand what was, was not and should be happening. I would put together a plan of action and sell it to management. I never really thought of it as a forte or specialization; red projects were the norm and they needed to be fixed.
In the early years, I had no authority to make the changes. I had to work through others to get the plans implemented. I started by working with bosses, superiors and managers; getting them to sell the ideas to the people who needed to implement them. I became very good at writing copious and thorough emails that would eventually be cut-and-pasted into someone else’s email to give the direction. I did not care. The project was getting fixed and I was excited to see the plans work.
Eventually people on the project would figure out where the ideas were coming from and they would start asking directly for advice, I would attend management meetings and would no longer need to work through their managers. This made it easier for them since they did not look so bad to their bosses, it made it easier for me since I did not have to deal with inaccurately relayed plans. The process was awkward and built animosity. It would have worked much better had the proper authority been handed to the person doing the recovery.
I was not always alone. As time went on there were a group of us, a SWAT team of sorts, dropped into a project to assess and fix the problems. Many times, we would stay on the project through completion.
I learned to make very effective use of the team as a tool. I would get the team aligned and have them drive the management. Befriending the key project team members, we would takeover the project to get it moving in the right direction. The management would eventually follow.
From this came a very important lesson. Good teams with bad management can be successful. They need to know the deficiencies in management and determine ways to cope with them. This became rule number one in recovering projects—the team knows what needs to be done. Finding the right people and exploiting their knowledge will get you to an answer very quickly.
At first this was a little hard to do and always felt somewhat subversive and covert, which, although it added a clandestine spirit to the recovery, was not always healthy. I have shied away from this, for the most part, but the team building techniques in doing this are invaluable. A tight dedicated team, with near gang-member mentality, is one of the most powerful and efficient groups you will find. It shows what a powerful team can do.
This led me to second lesson. Mediocre teams with the right inspiration and leadership can do great things. They are only mediocre because of the way they are treated. Looking at each person and leveraging their strengths, instead of using them to fill a slot, is essential. When a person has the wrong skills or training to do a task they will most likely fail.
To keep in touch with the team and make it stronger I had to stay a peer with them. I was their superior on paper only. There were many good and bad points in this.
Unlike many other Project Managers, I stayed in touch with the day-to-day activities. I did not remain in an office or my cubicle or court the executives. I was involved with the requirements, architecture, coding and testing of the product. I would even help write functional specifications or test scripts.
The goal was to keep management apprised; appreciation would come with delivery. Executives like seeing tasks completed, but they tend to forget about the project after it starts running well. This is good, in my opinion; the last thing I want is the CIO visiting my desk on a daily basis. I will overcome the disadvantages from lack of visibility.
To this day, my mode of operation is to get into the project, talk to the people, learn what is wrong, create a recovery plan, negotiate the details with the Project Sponsor, Executive Management or the Steering Committee and then disappear into the project, spending as little time as needed with senior management. Immersion in the project is by far the best way to fix it.
This led to the third lesson—stay immersed in the team. By doing this I can see and feel the project move. There is no need for status reports because I am there. I get all sides of an issue and can direct the team. I know the details and intricacies of the project at all times. The downside—summarization can be difficult. I am often asked "Can't you just give a yes or no answer?" My reply to that is "No... Oh, I guess I can. Oops, maybe not." People usually laugh. They may be frustrated with the verbosity, but they know that I am not shooting from the hip. If people want details, they get them quickly and completely. People rarely second-guess my understanding of a project.
This produced the fourth lesson—objective data is your friend. Most people know this as data is power. It is only powerful, however, if held close. Shared data is friendly. When faced with an issue or unanticipated question, fact-based decisions are the key to going the right way and being trusted to do the right thing.
Armed with these four lessons:
- The answers are in the team;
- A strong team can surmount many problems;
- Stay involved with the team;
- Objective data is your friend, providing the key out of any situation;
I join a project and work to fix its ills.
