Helping Project Managers to Help Themselves

Bud was one of the most brilliant people in his organization. Only in his mid-thirties, Bud amazed his senior managers with his ability to grasp problems and develop innovative and effective solutions to those problems.  He was highly sought after as a "go-to" guy and would consistently come up with creative approaches.  His management decided to give him a thorny project with a team of over 100 professionals.  "This is my chance to really prove I can deliver", Bud thought as he willingly accepted the project.

Bud wasted no time in coming up with some great solutions which his management thought were brilliant.  Expectations were sky-high and Bud was on a project high.  Then the problems started.

Though Bud did a great job of defining solutions, he had extreme difficulty articulating the work required to get from the current state to the desired solution.  He frequently lost patience with project team members when they brought up problems or issues and accused them of "stonewalling" the project.  Project risks were ignored and dismissed as trivial.  The team grew increasingly frustrated with Bud, the project schedule was in chronic slippage, and management grew increasingly concerned about Bud's ability to deliver.  Bud ultimately was removed as project lead.

Thought Leaders Aren't Necessarily Good People Leaders

In my years I've seen many great thought leaders crash and burn when they had to implement one of their creations.  In most cases someone in management made the assumption that because the thought leader came up with a great idea, that they could -- and should -- actually implement the idea.  This if-then relationship simply doesn't always hold water.  Unfortunately this lesson typically is learned the hard way; with the thought leader being thrust into the people leader role only to crash and burn. 

Now don't get me wrong; the world desperately needs thought leaders regardless of their ability to lead people.  What does need to occur, though, is a conscious recognition of whether a leader is a thought leader, people leader, or can do both.  For those leaders who are great thought leaders and not people leaders, don't expect them to implement large-scale solutions.  For those who are great people leaders and not thought leaders, don't expect them to design innovative solutions.  For those who do both well then enjoy the versatility and leverage it to the fullest.

The nugget here is simple:  decide if you are a thought leader, people leader, or you excel at both.  Then seek out assignments that best leverage your strength and provide the greatest value to your organization. 

Thought Leaders Design Innovative Solutions
People Leaders Implement Innovative Solutions

When I wrote my first book in 2004 my publicist told me, "you've got to write articles to get your message out and sell books!"  Being a good soldier I saluted and contemplated how I was going to get it done.   My publicist turned me on to a ghost writer who wrote an article under my guidance.  After paying way too much for the article and seeing the finished product, I vowed never again to have someone else write for me.  I decided that if I had crappy articles it was going to be because I was the one who wrote them, not because I paid someone to write crappy articles for me. 

Fast forward to today.  I've written hundreds of articles and locked down on a methodology to writing articles which stay on topic, aren't disjointed, and are easy to create.  Here's what I do:

Every article I write has four sections, as follows:

1. Opening story
2. Core message, or "meat" of the article
3. Take-aways
4. Close

If you look at my articles you'll be able to pick up on this structure.  The secret sauce comes in not the sections themselves, but the order in which the sections are written.  I write the article in the following sequence:

1. Take-aways
2. Core message, or "meat" of the article
3. Close
4. Opening story

Here's why I do it in this sequence.  I start first with take-aways because that is what I want my readers to get out of my article.  By starting with the take-aways, I ensure that I am putting the reader first and writing for the reader's benefit.  Next I construct the core message, or "meat" of the article.  The core message has to support the take-aways; if I've constructed the take-aways first then I better ensure the core message aligns to the take-aways.  Next I decide how I want to close the article, which is typically a one to two-sentence statement that underscores my core message.  The close leaves the last impression which needs to align to the core message.  Last, I write the opening story.  By writing the opening story last, I ensure that there is a relevant and seamless transition into the core message and that the opening story grabs the attention of the reader. 

When I use this structure, I not only get a better quality article, but can produce an article much faster than using the old method of "start at the beginning."  If you want to see an example go here. See if you can pick up on the article flow.  Happy writing!

A couple of years back I was engaged on a project to help recover an agile project run amok.  The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams.  The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result.  After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities.  To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project.  Our implementation looked like a mishmash of agile and waterfall.  It wasn't pretty, but we eventually got the project done.

Ah, agile development.  I love the speed, focus, and excitement of seeing capabilities roll off the agile  assembly line.  I've had the pleasure of running some very successful projects where we delivered capability much faster than under waterfall.  I've also been involved in recovery projects like my earlier example where the brand of agile being used was fraught with schedule and scope issues and management was demanding change to get the project righted.  Through these experiences a few tenets became painfully clear:

1. Business stakeholders want something when they want it; they don't care how well the project adhered to a particular development methodology.
2. Agile principle adherence shouldn't become the focus of the project.  It is the vehicle in which a project gets implemented, not the reason for the project.
3. Agile doesn't mean skipping any kind of testing, particularly integration and regression testing. It just means you are compressing and overlapping and being less "over the wall" in test stages.
4. Successful agile requires focused business user involvement through design, development, and testing.  None of this "let me know when it's done" stuff.
5. Top down project management orchestration is crucial.  Empowering teams is important, but can't be taken to a point of anarchy.

Depending on where an organization is at in its systems development methodology journey, it may not be able to jump to a purist agile model and be successful.  I've learned that the following six principles are paramount in a successful agile project.

1. Embedded Power User - Having an experienced and forward-thinking dedicated user who can guide capability development and bring other users to the table as needed ensures that the capabilities under development will align to the business and will minimize capability gaps after implementation. The embedded power user also has a responsibility to know and communicate the current shortcomings as well as clearly articulate future state capabilities.
2. Time Fences - Rather than having team members set their own delivery dates, the project team needs to work to defined time fences and flex the work to hit the time fence.  Key to this is the project manager having some flexibility to alter a time fence if it makes sense to do so.
3. Governing Architecture - I watched an agile project with six capability teams go off the rails because each team was given too much architectural freedom of choice.  About five sprints into the project the capabilities didn't fit together because of individual decisions made by capability teams, creating massive rework.  There needs to be a concise functional and technical architecture that capability teams must snap to.
4. Small, Frequent Deployments - I like executing plans that have monthly capability releases.  It keeps the energy going, gives business users and stakeholders something to look forward to each month, and gives everyone something to celebrate each month. it also exposes weaknesses and integration challenges sooner than later.
5. Persistent Testing - Developers tend to like "grand reveals." where a capability isn't shown to others until the developer is sure everything works 100%.  I prefer to have testing and power users involved as close as possible to development to find problems early on.  There is a big trust issue that has to be overcome when you take this approach; the developer needs to not be randomized by "Are you done yet?" questions and needs to know that if something breaks during development the power user won't start launching flares that the product is of poor quality.  The developer, in turn, needs to avoid  the grand reveals where fixing problems later in the schedule becomes more expensive.  This also keeps the power users honest by minimizing late-breaking statements like "that's not what I want".
6. Strong Project Management - Agile isn't code for anarchy, and it's not a time when the PM is relegated to administrative errand-running.  The PM needs to be driving accountability, ensuring issues are being addressed,  risks are being mitigated, dates are being met, and scope is being adhered.  The PM also sets the communication rhythm for the team and works to keep the team on the same page. At the end of the day, the PM gets the first bullet if the project fails and needs to ensure everyone is doing his or her job to meet scope, schedule, and budget goals.

I've never seen a project manager get points because he or she followed the rules of agile on a failed project.  The first and foremost goal is agreed-upon scope delivered on time and within budget.  Keep the above principles in mind as you take on your next agile implementation to better ensure success and not get tied up in whether or not you're doing agile right.

As a young manager I was on a particularly difficult assignment that had attention all the way up to the CEO of the company. The executive leading the project was a very seasoned and intentional leader who executed as well as anyone I’ve ever seen drive a crisis initiative. His ability to stay on top of the work was like nothing like I’d ever seen from other leaders in the organization. During my annual review with him, I asked what he saw as a crucial attribute of a successful leader. Without missing a beat, he gave me two words which continue to shape me as a leader: follow up.

Through the years I’ve seen how follow-up (or lack thereof) contributed to a team’s ability to successfully deliver results. Organizations that have follow-up in their DNA simply execute more friction-free than those who don’t. The leader stays better aligned with the work happening in the organization, and the followers better understand and execute to the leader’s expectations. I’ve seen it in my own experience as a leader. As my leadership skills matured and my follow-up ability became more autonomic, I saw first-hand how we were able to get things done more effectively. I also saw another benefit--my timely follow-up behavior reduced the number and magnitude of crises I had to deal with. I was more on top of what was happening, was better in sync with the team, and more engaged when the team needed my help to get something done.

Fostering a follow-up culture isn’t difficult to do, it just takes discipline. Get the ball rolling by instituting these seven follow-up tips:

1. Be known as a follow-up fiend – Simply put, when people know you follow up on commitments, they’re more likely to do what they agreed to. Be consistent and timely with follow-ups and do it every time. Followers know those leaders who follow up and those who don’t and are more likely to shirk responsibility if their leader’s follow-up is inconsistent or absent.
2. Establish a follow-up cadence – In my article Intentional Empowerment I talk about the importance of a follow-up cadence when empowering someone to own solving a problem. A deliberate follow-up frequency is crucial to ensuring that you as the leader stay abreast of progress, as well as being available if your help is needed. Make sure you set an appropriate frequency, establish clear expectations on what will be done in each follow-up meeting, and that you live up to the follow-up commitment.
3. Establish singular points of follow-up ownership – Follow-ups assigned to “the team” mean no one owns it and it’s less likely to get done. Ensure any follow-ups you give have a clear, singular owner who can be held accountable for delivery.
4. Get them to summarize the what and when – At the end of a meeting if there are follow-up actions required, ask the accountable person to send you an email describing the follow-up action and when it will be done by. Asking them to do it better ensures an understanding and agreement as to the follow-up action and due date. After you get the email, copy it into your calendar on the follow-up due date for you to do then follow-up either in-person or by email.
5. Acknowledge actions – Great follow-up leaders treat follow-up actions as important and followers want to feel their work wasn’t done in vain. When someone follows up on an action you requested, don’t just be silent. Even a quick “Thank you for following up” response tells your followers that their work was important enough for you to take the time to act upon it.
6. Be real – If a follow-up was well-done, say so. If it wasn’t, say so. Creating a follow-up culture means you encourage good behavior and correct bad behavior. Be courageous and direct with both encouraging and correcting.
7. Walk the talk – The best leaders who drive accountability through follow-up do what they say they’ll do when they say they’ll do it. They do it not only for their leaders but also for their followers. When followers can rely on their leader to live up to a commitment, it not only sets the example of follow-up, but also speaks volumes as to the leader’s integrity.

There’s simply no reason not to establish and foster a follow-up culture. Just take the time to make it top-of-mind and instill the importance of it to your team.

In 1985, The Coca-Cola Company introduced a new formula for its Coca-Cola product, calling it “New Coke.” Consumer reaction to the new formula was negative, and within three months the original formula was revived and rebranded as “Coca-Cola Classic.” The company was faced with a decision-- keep the new formula and try to change consumer perception or abandon the product. The New Coke product was ultimately discontinued in July 2002. As the company navigated their choices, the alternatives were about how to recover from a bad situation, with its management faced with minimizing a profit hit and negative consumer sentiment.  Their decision path ultimately worked out well, but the decisions along the way were painful choices meant to minimize loss.

A huge part of a leader’s job is making decisions based on informed alternatives which articulate both the positive and negative consequences of the decision. The typical mode of operation is to look at pros and cons and do a pros to cons weight assessment of which alternative’s pros best outweigh the cons. But what about when there aren’t any pros, yet a decision needs to be made? I’ve seen leader decision-making hobbled because there is no good alternative in the decision set, looking for pros in a sea of cons. There’s no good alternative, so it’s about choosing the least-worst alternative.

The mechanics of least-worst alternative management are really no different than looking for a best alternative. It’s all about the mindset decision makers adopt when embarking on the decision. Being overt about recognizing the chosen decision isn’t about bringing benefit, but about minimizing hemorrhaging. It gives decision makers the freedom to make the best decision without the burden of justifying the lack of pros supporting the alternative.

Next time you are faced with choosing between worse and more-worse alternatives, keep the following six factors in mind:

1. Forget about perfection – Perfect alternatives with no downside rarely exist. Don’t put unrealistic standards on decision alternatives that can’t be achieved.
2. Set expectations with decision makers up front – Be deliberate with the decision-makers that the alternatives aren’t optimal and that you’re looking for the least painful course of action. Using the term “least-worst alternative” helps cue decision makers as to the type of decision they’re making.
3. Ensure the right people are involved in the decision making – looking at worst-case alternatives may mean including additional people, i.e. someone from the public relations group in a decision affecting customer perceptions, to provide input. Be clear on whether they only provide information to support decision-makers or are included as decision makers. 
4. Articulate worst cases for decision alternatives – For each alternative ask the question, “What’s the worst thing that will happen if we do this?” Make sure the worst case is reasonable and aligns to the organization’s mission and values.   Also be on the lookout for unreasonable “the world will end” scenarios from pessimistic decision makers.
5. Assign a singular accountability owner for the chosen alternative – Alternatives that have fuzzy or undefined ownership most likely won’t get done. Ensure there is a singular named owner of the alternative with clear articulation of what needs to be done and when it needs to be done by.
6. Define a follow up rhythm – Define how and when the accountable owner will update decision makers on chosen alternative progress and what the course of action will be in the event the chosen alternative is not working. Also be clear as to whether updates will be via meeting or email.

Navigating through bad alternatives isn’t fun, but having the ability to skillfully and objectively get to a least-worst alternative is a crucial skill the best leaders possess. Keep top of mind whether you’re making a maximize-benefit or least-worst decision and ensure your decision makers understand the type of decision they’re making.