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!
Great Product Features Have Solid Business Case
For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God. Instead, they come from lowly customers here on earth.
Here’s how it happens:
A customer calls up and says, “Why is your product so lame? Why doesn’t it do such-and-such?”
“That’s none of your business!” cries an eavesdropping passerby.
Oops, no. Not the correct response. Instead I ask, “How would you like it to work?”
Nine times out of ten that question turns into a great new feature. We discuss the business case and work out an alteration that fits the common usage much better. Customer is happy; we’re happy. Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable? Because it comes from an actual customer with little vested interest in the product. They just want it to work better so they can get their work done faster.
BINGO!!!
That’s the key. Anytime you can reduce admin time or improve product usage, everyone wins. Nobody likes a hard product. Dreaming up great new features in a boardroom rarely accomplishes those basic goals. Talking to customers is where it comes from.
Problem is, who’s talking to customers? Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed. These are the lowlife employees nobody listens to. So how does the customer need get filtered up the channel to executives and then back down to the development team?
Give them a database. Let them submit feedback from the trenches. If they can articulate the business need clearly and effectively, people will listen. The best features always come from customers.
Reach out to new kids
I remember my first software development job in 1992. I joined a software company that developed for the “new” Windows operating system: Windows 3.0.
As a junior member of the team, I was deathly afraid of revealing what I didn’t know and lose my coveted new job. I was sure everyone on the team knew more than I. So worked 72 hour weeks to catch up. I studied, and coded, and watched, and listened, and tried to fit in as best I could. It worked perfectly! But it turned out I wasn’t the only newbie, and I learned that I knew more than I thought.
So now as a project manager, I’m sympathetic to newbies. No newbie will lose his job just because he hasn’t been immersed in the latest technologies. Reach out to the “new kids!”
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.
Why Foundational Features Matter
Let’s say you know customers need a really complex feature, but your project team only has time for a basic implementation. Do you wait until you have team resources to build the full implementation? Or do you just build a basic foundational product that doesn’t actually meet any current customer requiments?
My answer: Start with the basics. Add later.
Foundational product features are usually enough to sell the full implementation. Customers can see that you have a percentage of what they need. That helps them have faith in a full implementation at a later time. They know it’s just a derivative of your current implementation. But without something tangible to demonstrate, they won’t believe you’ll do the feature at all.
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?
Ever Have One of Those Meetings?
I was in an important meeting and the project team pretty much knew that a certain person wasn’t carrying their weight. This person wasn’t a complete let down…but could do more. During the course of our project meeting an issue was raised as to why a task had not been completed. This person became defensive and started pointing fingers and making excuses. I lost it. A normally mild manner person, I let him have it. I gave him the what for and how come. However, I was out of line and spent hours in one on one meetings apologizing to this person and the rest of the team. There is a time to kick someone in the pants and a way to do it. My way that day was wrong. It costs our team more time in apologizing then this person not completing their task. The bottom line is we have to play the game with the team that we have. There isn’t always time to replace someone and many times there isn’t anyone else available…period. My advice…if you aren’t getting the job done, own it and move on. People respect that more than excuses. Secondly, be slow to speak or you may make a situation worse. I know, because I did
The Gantt Chart and Daily Project Coordination
All project managers have used or at least heard of a Gantt chart. The Gantt chart was created by Henry Gantt around 1910 and still widely used today. It was used in major projects like the Hoover Dam. Henry Gantt designed the Gantt chart to help manage project scheduling and work progress. If you read his book, Work, Wages, and Profits (1916), you will note that Gantt believed it was imperative to communicate daily schedules to key players and by not doing so rendered schedules useless. Gantt thought it was important to be a project coordinator, to coordinate activities, and reduce conflicts. I think this is an important and often overlooked part of being a project manager. We often look at the larger picture and fail to identify “Daily” influences that cause project slowdowns. We should have daily expectations and identify barriers to those expectations each and every day.
Reference:
Gantt, H. L. (1916). Work, wages, and profits. San Diego, California: University of California Libraries.