Category Archives: Project Management

Balancing a Strong Plan and an Open Mind

It is exciting and fun to blog about innovation and the value in always keeping an open mind in your projects. The smallest idea from the least likely of sources may lead to toward incremental value and innovation or truly substantial change. But somewhere along this path of continuous improvement, you need to find the lines in which to hold your project team. That is where your various management plans and PMP will come into play.

The time spent developing a collaborative PMP with your team will help them come to understand the constraints and goals of the project. Without having to reign in their creativity too often, their buy-in up front will pay dividends from that standpoint. It is also important to encourage them to use the PMP guidelines as a tool just like any other. Without stifling their problem solving capability, you have to keep things within reason. Your PMP will help to guide the team, but like all guides, they are meant to point you in the right direction only yet let the team decide where to take each subsequent step.

At the end of my decision making process, I will typically err on the side of an open mind. Whether your style as PM is to start with strong project controls and definitions and then relax them as needed or to firmly make every decision within the agreed-upon constraints of your PMP, your approach can work well. My style is to innovate along the way using every possible resource. Without a doubt, I have found at times that I would have been better served to have adhered more diligently to the original course. However, more often than not, I have found that a great team can handle change if they want to; that is, if they believe in the innovation or change, and you do to, then make it happen. Period.

Every PM is going to be caused to find the balance between their delivery constraints and goals and their desire to maximize value through innovation. This balance will be unique to every PM and perhaps on every project. There is no right answer, but it is a balance that every PM should be conscious of because managing this balance is a large, unspoken role of a great Project Manager. Good Luck!

Advertisements

The Value of a Plan

It doesn’t take a single week in project management until you are introduced to the all-powerful concept of the Project Management Plan. The opposite of a one line vision statement or strategy, your PMP may consist of double digit number of sub-plans, each with multiple pages themselves. Suddenly, this PMP may seem like a mini-thesis outlining how each of the members of your team should conduct themselves. The question in my mind can become, “don’t these folks already know how to deliver a project? Certainly they know better than if you tell them how to do it?”

The fact of the matter is that your team members hopefully do know how to deliver a project better than you do. That is why you chose them for your team, because they are smarter than you. So your role needs to be to solicit and incorporate their input into the PMP. Guiding them within the known constraints of the project and asking probing questions to help define the boundaries, metrics and goals. With your expert team’s full input and buy-off, you are more than half way toward success!

The problem is that this last step can be fairly involved with no rewards in sight. Many a great project has been delivered through on the fly consensus between a strong group of open minded individuals. Why put in so much effort into a PMP when it may not be needed?

This point is hard to appreciate until you see the value of a plan realized through execution. It is only well after the PMP is developed and endorsed by the Team that you often begin to see the tremendous benefits of the thoroughly understood and agreed-upon constraints, metrics and goals. Furthermore, it is easy to lose sight of these agreed-upon elements of the PMP during the interim time. Consistent reference to and emphasis of the PMP milestones will keep your team aligned and ultimately will show all of your team members the Value of a Plan.

Good Luck!

Staying Ahead of your Innovation

It has often seemed like a bit of a conundrum to me to manage innovation. Developing a plan inclusive of a schedule and budget is fundamental to every PM’s role on a project. How on earth, then, is this supposed to be accomplished if you are going to be breaking new ground with a process or product which has never been developed quite like this before? Can your plan include a 100% contingency for time and money, just in case you have to start over 3 times before you can deliver? Doubtful. Instead, let’s discuss some options for the PM to flex with change yet deliver on their goals.

Multiple Options – Always have a Plan B. Do you know what you will do if Plan A fails? In many projects, this secondary option is given very little thought. Some are extreme hypothetical doomsday scenarios and others are just such well-established deliveries that the likelihood of failure is miniscule. However, in an innovative process or projects in general, you need to have that fallback plan on hand up until the last minute to stay flexible.

Broad, yet Firm Constraints – What if your process involves developing an innovative widget by xyz date and that’s it. Like an independent study of sorts, this is for the advanced team. Performance based management. With regular ‘check-in’ meetings and firm end goals, your team will find the path. Don’t micromanage the process, there is nothing to manage. Let the team find their own way and you just stick to the end date and budget.

Manage the Mindset – While the team continues to succeed, constantly challenge them with ‘what if’s’ and curveballs. It is easy for teams to get locked into one solution and it is a fine line between over-taxing their psyches and supporting their successful decisions. Constantly keep an eye on the team’s view of where they are headed and how they will get there. Never let it get too stable.

You have to plan for flexibility in your project management from the start in order to foster and have the ability to incorporate innovation. Then through specific management approach you can encourage greater innovation from your team while staying nimble enough to adopt change through failure / innovation.

It is never an accident!

The DO NOTHING Option

Driven to act. Do more with less. Faster. Cheaper. More.

When we are discussing efficiency, innovation, or general project management how often do we discuss the ever-present option to “hold”, “punt”, “fold”, or simply DO NOTHING? This less-glamorous, inverse-of-innovation is counterintuitive to corporate culture and needs a refresher. When is the best decision the decision to walk away?

I’m not referring to the catch-phrase-of-the-day “kicking the can down the road” sort of doing nothing. I’m talking about the strength and wisdom necessary to walk away from a project when the truly best option is to let it lie. Yes, I said true strength and wisdom. Wisdom to know the difference between “questioning everything” and zero progress.

If taught and asked to generate true value, can you question the initial premise itself? Absolutely. Is there really even a project here, or are you only managing the project from handoff to handoff? The fact is that this question is valid, but it will only generate value if it is as carefully and objectively analyzed as any other innovation-motivated breach of protocol. Put the Option through its paces in an isolated, unbiased discussion of merit. Sunk costs and political pressures aside…should we walk away?!? Now consider this potential project from a program perspective and whether or not there are more effective ways to spend this project’s budget.

Management of the discussion of this option takes practice as does all innovation management. However it is a valid option which is woefully underrepresented in the discussion of value creation and innovation. If we are asked to do more with less, are we achieving this goal by doing nothing?

That’s not how they did it back at my old job…

How many have heard folks in teams make that statement, “…when I was in XYZ organization, we preferred to do this process 1, 3, 5 not 1, 2, 3…”? Now, how many of you resented that input from your team member and virtually immediately shut your mental door to the potential merits of their approach?

What I would like to discuss is why did you do that, and why did they do that?

First, why did they do that? Chances are the correct answer is the most simple one: they are searching for areas of familiarity and comfort in a new team. Your process, the new organization they are in, and this new team are just that; new – and therefore uncomfortable. Not necessarily wrong, or bad, just new and different. They would prefer a familiar process for sheer comfort. Human nature and not a bad thing within teams, you just have to recognize it and manage it when you see it.

Why did you do that? Same root cause. Chances are that your process is one that the rest of the team members are familiar with and so are conversely uncomfortable with the suggested revision. Simple as that. Change is uncomfortable and if presented incorrectly, it will be exiled immediately.

So at its core, you have a team member recommending a change and another team member objecting to the change on contact. This can put you as a PM in a unique position to re-frame the proposed change as a consideration from yourself rather than one that has perceptions of bias or superiority. Your team members all want to have the best project possible and it’s not like they haven’t had to deal with a change before. All you have to do to salvage this potentially great piece nugget of improvement is to repackage it as your team’s idea. Not “how it was done in XYZ”, but “what if we did 1, 3, 5.

It’s all in the presentation. Put yourself in a position to deliver and your team in a position to receive…then watch the success grow!

Conflict Resolution – When all you want to do is fight

Like darn near anything you are going to hear along the lines of project management, one of the keys to successful conflict resolution within a team is establishing a plan before the conflict occurs and gaining bipartisan support. When things are still rosy, agree that when you do (and you will) disagree, that there will be a time limit and a process for resolving the issue. There are several reasons for this:

You have to know when to say when on an issue – You aren’t going to change anyone’s mind after several attempts and you just need someone else to make the call. The project has to move forward and a festering conflict can stagnate and contaminate the entire team. Move the resolution on and get back to business.

Perhaps even you could use a fresh perspective – Luckily for you, like myself, you are never wrong. Perhaps the conflict could use a new set of eyes with, let’s say, a broader perspective. Focus on what matters and move on.

Allows you to isolate and contain the conflict – When it gets bad, it will be everywhere. In everyone’s minds, in their whispers, in their body language, and in their emails. The negative spiral has begun and you can forget about partnership. Avoid this death spiral by cutting the toxicity out before it infects your team. Isolate and escalate the issue per your resolution plan and keep the business at hand, at hand.

When you agree to escalate the conflict from the project level, you are attempting to preserve the harmony within the team as described above, however you may likely also be losing some of the facts and context surrounding the issue in the translation. Remember that no one is better suited to deal with the conflict resolution than those closest to the actual issue. They know what happened and what the facts are better than anyone. If they are unable to see through their emotions or find a common ground, you should strive to resolve the issue at your level; or someone else at the next level will – you just might not love the answer.