Remember the expense delays in opening the brand new Denver International Airport? Many case studies have been done examining the intricate reasons for such a colossal failure on a grand scale. DIA was to be the most efficient airport in the world, able to accommodate over 50 million passengers per year. One of the key components was to have a fully automated baggage system…eliminating the tug and trolley system. This would cut a planes turnaround time by 30 minutes and would be a key component in creating more efficiency with flights and passenger throughout. The chief project manager, Walter Slinger had his heart set on this shining new system and romanticized about the notoriety the state of the art airport would bring to the city of Denver. BAE also liked the idea of designing a system that would garner great attention and further their own reputation for building baggage systems. Again, you could read many in depth case studies about the key decisions that led to the cascade of delays and failures. However, I would summarize them in a single manner, tunnel vision. Both parties fell in love with an idea and ignored many internal obvious warnings about the baggage systems feasibility. The delays were numerous and cost billions of dollars. In the end, after many attempts to partially use the automated baggage system, it was virtually scrapped for the more economical tug and trolley method. We all know the old saying that our eyes are bigger than our stomachs? If you’re a project manager, make sure your love of an idea isn’t greater than your team’s ability to design and implement the idea. Don’t be afraid to change directions. Otherwise, you may be the next DIA, which is still one heck of an airport!
Project Quality Assurance
Project quality has many facets depending on the type of project and the quality objectives. A few common metrics used are guidelines and standards. Most people understand the difference between the two. However, guidelines can be confused with standards. Guidelines are just that, an idea or parameter to stay within. Standards are a more exact objective to be met. It is well worth while to make sure people are clear on the differences and expectations of each. Otherwise, a small misunderstanding can be costly. As an example, a sorting team was tasked with looking through thousands of figurines to inspect for defects. The guideline says the figurines can have up to 3 blemishes on the front portion, no larger than 2 cm each as long as they are not on the face. The Standard stated if there is only one blemish allowed in the facial area and they must be less than 1 cm. Well, an entire shift didn’t understand the difference between the guidelines and standards and inadvertently allowed figurines to pass through that had single blemishes on the face up to 2 cm…double the allowed size. This was caught during a random audit and thousands of figurines had to be re-sorted costing the company hours of productivity, not to mention money. As cliché as it may sound, never assume anything. Communication is vital. A simple misunderstanding can cost an entire project.
Ethics in Project Management
With all the pressures of managing a project, it is easy to be swayed and make poor decisions. Pressure can cause a person to rise to the occasion, or crumble in a pile of heap. Most often, however, a person may do things they thought impossible…cheat, lie, twist the data? Unfortunately, this happens more often than we would like. As a project leader it is important to maintain character and integrity. Short term gain based on any type of shenanigans will cause long term pain. For example, say you’re leading an IT project and your developers are having trouble meeting deadlines. You instruct them to “dump” a few outlying features…the customer won’t even notice or use that feature until long after we are done. It’s not a big deal. Two things are going to bite you, one is obvious, the other not so much. The obvious gotcha will come when the customer realizes you didn’t fulfill one of the expected features and becomes upset and makes some waves. The other less obvious problem, your team won’t trust or respect you. They see clearly how you manipulated the situation and trust is broken…even if they agree and would have cut corners too! Take the issues head on. Consult the customer on the scope and change and instruct your team accordingly. You may disappoint the customer now, but your project will keep integrity and your project team will respect your leadership.
Planning for Pathological Issues
One of the more recognized terms in any business is Paralysis by Analysis…or Analysis Paralysis. You know, when nothing moves forward because too many people have to buy off on an idea, or a single person is the team lead and afraid to jump in with both feet. Well, I believe one way to identify Analysis Paralysis is to look for the most common symptom…pathological cases/scenarios. This is easy to spot. When “what ifs”, that are highly unlikely continue to pop up, then you can get stuck in the “what if” cycle, causing Paralysis by Analysis. These pathological cases have a sliver of possibility but cause an overwhelming fear for the project team. Then you’re off trying to plan or prevent the impossible. I have seen this happen many times and more often than you may think. Project leaders and team members can easily become myopic when focusing on their work. In my experience the best way to tackle pathological cases is head on. Politics is one thing, but a never ending project is another.
The Collaborative Process in Project Management
I understand the latest fad in management styles is the collaborative process. Part of the collaborative process is encouraging multiple people to arrive at a decision as a unit, or on behalf of the unit – where, in times past, there was a “buck stops here” person. Now there is a buck stops here, over there and just about anywhere group of people. While the collaborative process has a place and is effective in many scenarios, it is dangerous when it bleeds over into a non-collaborative project structure. I’m not saying project teams shouldn’t work together to collaborate and solve issues. In fact, just the opposite! Project teams are a TEAM by definition, working together towards a common goal. However, with a younger generation being taught the collaborative process so heavily, it can cause issues when they veer out of their lane and bypass a structural hierarchy or chain of command. The collaborative process is great until a person makes a decision without actually collaborating with the person/persons responsible for that particular area of concern. By the time the “true decision maker” finds out, the decision has been made, announced and partially implemented. Now we have a real mess. Collaborate on that!
The Common Error in Estimating Projects
I recently read an article on the PMI website about bad estimates and project cost overruns. The article was by Dr. .James T. Brown. Dr. Brown talks briefly about the typical political and personal pressures that cause failed estimates. However, one of the more interesting items listed in the article is recent Oxford Review on Economic Policy. The review studies infrastructure estimates and has a comparative graph showing road/bridge type projects vs. IT projects. Guess which one is more commonly underestimated? Here is a link to the article… http://www.pmi.org/en/Knowledge-Center/What-Causes-Bad-Estimates.aspx
Project Tasks and Issues Tracking
You identify the scope and nature of a project. Design the project plan and assign resources and begin the process of real work and plan executions. Many tasks follow a predicted path and glide down the slope toward completion. Others hit speed bumps and issues arise. If you only encounter a few issues along the way, they are fairly easy to manage with emails and spreadsheets. The issues still require special attention and follow up costing time and energy, but manageable. What happens if you 130 issues arise in a short period of time (as is often the case in software development and bug fixes)? Spreadsheets and emails won’t cut it. In no time you lose track of events, issues and milestones. I am pointing out the obvious. But I have counseled hundreds of project managers using outdated tools and methods to track issues. Maybe project management and issue tracking software/tools cost a little money (others cost a lot of money), but believe me, they will pay for themselves many times over in saved projects, efficiency and ultimately the bottom line.
Seven Days in Utopia
The movie Seven Days in Utopia is clearly not up to Robert Duvall’s standards. The story points were awkward and difficult to decipher. One-shot git-er-done scenes and Karate Kid theme didn’t help. But I managed to scrape out the movie’s arc and purpose. It’s about faith and trust in God… and a little golf thrown in.
Buried in the poor directing was a principle that resonated with me. Duvall’s character says, “The game of golf is about conviction.” He continues with, “Watch out for that random idea that comes at you, that will throw you right out of your game. Without conviction, it will make you question your game and shake your confidence. Without confidence, you cannot win.”
It occurred to me that project management is exactly like that. Without a clear strategy that rests on bedrock conviction, random ideas from so-called experts will shake your confidence. You’ll chase a dozen “great ideas” from outsiders and never execute your strategy. Although while that’s true, you must still remain open to new input. It’s a touchy game.
Moral of the story: Develop a solid project strategy and hold your confidence. Follow through with confidence.
Trust Me, I’m a P.M.
An often overlooked step in the project management team is the project/client representative. The person responsible for being the messenger, intermediary between the project team and the client is a critical role. Larger companies pay professionals to strictly fill this role, while smaller companies often let the PM handle that role. This is fine in most cases, unless your PM is not good at customer relations. Customer relations’ professionals spend their entire day thinking of how to build trust, gain confidence, and maintain a relationship. Project managers spend their day doing this on some level within their project team, but it is not their main focus. If you are good at customer relations it will make the project run smoother because the client will have a certain level of trust. If you are not, the project becomes hindered. Why? Because, the client doesn’t have a needed level of trust in you, they begin to question your work. Now the client wants more status meetings. Maybe the client begins to micromanage your project and requires more of the project manager’s time and attention? This can quickly snowball because of one misunderstood statement that breaks a fragile trust. Whoever is communicating with the client, make sure it isn’t General Patton. While he gets the job done, in the project world he would make the job more difficult.
Groupthink…Project Killer
Susan Cain just wrote a piece in the NY Times talking about the destructive force of groupthink (article found here: http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all). This started me thinking how groupthink applies to project management and the synergy created or hampered within a project team.
After reading the article I am more convinced that as a project manager it is important to encourage and draw out people’s experience and opinions. It is imperative that project teams have a voice and strong leadership to maintain project goals while remaining open to the team voices. Otherwise, we have the inverse problem. Instead of shortsighted groupthink that has little innovation and a blind rudder. You get analysis paralysis where the goal is clear but the wheels just spin. Which is worse? Probably about the same…nothing gets done, or it does, but it is completely wrong and misses the mark. What do you think?