Strategic Project Management

I have been fortunate over the course of my career to benefit from the advice of some very smart people who were willing to mentor and teach me. That being said, I wish I could say that every "boss" or manager I've worked with has been a mentor, but I can't.

Over the last ten or so years I've had the opportunity to be on the other end of that equation and have been in the position to work with a number of young people just starting out in their careers. I am energized by their enthusiasm, their drive to perform and the skills they often bring to the table.

With that being said, throwing them into the deep end of the pool to see if they sink or swim isn't smart for the organization, isn't good for the projects they contribute to and is just a bad management practice. Several years ago a colleague of mine and I were talking about the younger members of our team. We had intentionally hired fresh faces out of college because they were less expensive. I have since come to appreciate that what you don't pay in salary to less-experienced team members, you must pay in coaching and mentoring. Nobody enters the workforce with all the skills they'll need to  successfully contribute to a project team. There are a lot of things we learn "on the job" regardless of our field of expertise.

As a project leader, you may find yourself from time to time in the position of mentor and coach. If you do, remember the Three Ps:

1. Patience: Whether you're the coach or the person being coached, this is an important P. In a perfect world people don't make mistakes—we don't live in a perfect world. Mistakes are part of working with people. We need to be patient when less-experienced team members make mistakes. What's more, it's likely they will make the same mistake more than once. Frustrating to be sure, but it's seldom the end of the world. In reality, it's part of what it costs to work with younger people. And, in reality older, more senior team members make mistakes too. I've come to appreciate that it's a part of working with project teams. Projects are messy and unpredictable things. When people are stretching and creative problem-solving, sometimes stuff happens. Be patient.
2. Practice: Part of learning any new skill is practice. Not only is it important for the person being coached to take time to practice, as a coach or mentor, it's important to create an environment that gives people time to practice and learn. Unfortunately, there are a lot of things that require doing them over and over again to get them right. It's been said, "That which we persist in doing gets easier, not because the nature of the thing has changed, but our power to do so is increased." Practice might not make perfect, but is an important P. Practice.
3. Persevere: Giving patience and practice time to bear fruit is critical to success. I've seen a number of very talented people fail to persevere when times got tough or situations become challenging. This applies to both the mentor and the person being mentored. Winston Churchill famously said, "Never, never, never give up." Although never is a long time, perseverance is a critical P. Don't give up.

What are you doing as a project leader to coach and mentor younger members of the team? Feel free to share your ideas and suggestions.

Sitting down at my desk this morning, I actually laughed out loud.

Although there was nobody here to witness my outburst, I still looked around the office to make sure. There's nothing quite as disturbing as a lone man in the semi-dark of the early morning office laughing out loud.

I have always thought of myself as a pretty spontaneous guy. In fact, I've always prided myself as being able to think well on my feet and deal with new situations as they arise. This morning I had to face my demons. I am really quite predictable.

With few exceptions, I drive into work, park in "my" spot, enter the office by the same door, climb the stairs and put my bag down on the same corner of my desk the same way every morning. I extract my computer from my bag, remove my notebook, hang up my jacket and pull yesterday's calendar page of my desktop calendar. I had to laugh. What's wrong with being predictable?

About this time last year I read a post by Richard Lawrence that has resonated with me. He's a certified SCRUM coach who writes about software development and making software teams happier and more productive. Lawrence suggested that dev teams should focus more on being predictable than being productive. He argues that increased productivity will fall out of a predictable approach to software development. I have since thought that a more predictable environment would also benefit other teams.

Lawrence suggests that a focus on predictability helps a team:

1. Develop and complete smaller projects that can be completed in a day or two. I like the idea of breaking down the work into smaller chunks. Although there will always be larger projects with time-lines that stretch out to months or longer, breaking up those projects into shorter durations will complete-able deliverables allows teams to show value at more regular intervals. This is good for stakeholders, team morale and ultimately project success.
2. Work on a smaller number of project deliverables at once. I once worked with a fellow who was incredibly productive if he only had a couple of project deliverables on his plate at a time. Less than that and he would fuss over a project deliverable forever—more than that and he would be so overwhelmed that he would freeze up and accomplish very little. Admittedly, every team member is different, but keeping expectations reasonable (in my opinion) helps project teams be more productive.
3. Ensure that the definition of done that is identified before the project is started is the same definition of done when the project is completed. I've noticed that the longer the duration of a project, the more likely the definition of done will morph into something other than what was originally intended. Sometimes this might be the result of scope creep, but often it is the result of unforeseen impediments that over the course of a lengthy project make it difficult to completely accomplish the goals or the initiative.
4. Enable individual team members to cross disciplines to get things done, avoiding unpredictable wait times. Shorter duration projects often encourage team members to step outside of their "defined" roles to get things done. Which, after all, is what getting things done is all about, right?
5. Make achievable commitments based on past results. From a management perspective, it's easier to predict the results of a series of shorter duration projects than it is to predict the results of a project that will drag on for months at a time. From a team member's perspective, it allows them to feel a sense of accomplishment at regular intervals. Most people respond well to feeling a sense of accomplishment at a job well done. The more often they are able to do that, the more productive they will be.

On the other hand, Lawrence suggests (and I agree) that a dogged focus on productivity usually leads to:

1. Individuals optimizing for their own productivity (i.e. lots of tasks getting done—a focus on activity rather than results)
2. Over-committing
3. Starting projects without necessarily believing they'll get done in the time-line required
4. Sacrificing quality for speed (i.e. "Just get it done; we'll clean it up later")
5. Communicating and collaborating less ("All that conversation slows me down. I need to focus on my work")

Lawrence argues that a strict focus on productivity might increase a project teams ability to get more accomplished in the short term, but focusing on predictability is a better long-term solution for helping teams increase productivity.

I have to agree. What's more, making it happen might even be easier than you think. Although projects aren't usually considered repeatable work, there are many aspects of a project that can be templated to be made more "predictable." Applying templates to parts of the process that make sense makes project planning easier, encourages the capture and implementation of best practice and helps ensure a successful project outcome.

Is predictability part of your methodology? How do you utilize your project management tools to increase predictability and ultimately productivity?

As a young man I worked in my fathers industrial supply business. I worked in the warehouse and drove the delivery truck. We sold fasteners of all kinds, nuts, bolts, screws, cotter pins and other industrial supplies. I learned about screw pin anchor shackles, concrete anchors, structural bolts, machine tools and other industrial/construction-related tools and equipment. Visiting industrial sites all over the Utah, Idaho and Wyoming, I also learned about how they were used and their value to equipment and machinery.

The linchpin has always been an interesting fastener to me. It's small, not particularly strong; but when used to keep the wheel of a piece of machinery (or even a small go-cart) on an axle, it's indispensable. Without the linchpin, the wheel will eventually spin right off the axle—resulting in a catastrophic failure.

The same is true with project teams. There is a linchpin, and the success or failure of any project rests on that linchpin's ability to perform. It's not the project manager. Nor is it the project sponsor or the particular methodology the team uses to get work done. It's not even the project management software or other tools employed by the team to facilitate collaboration, report on progress or manage project deliverables.

Unfortunately, from a project management software perspective, the linchpin is often ignored. It's probably because he or she isn't involved in the purchase decision, has no budget, has no purchase decision authority and it's felt that the needs of project managers and stakeholders are more important—at least they often have budget and the ability to purchase products.

In reality, it's the individual contributors on a project team that keep the wheels rolling, and regardless of your methodology or software tools, in my opinion, ignoring the linchpin is one of the reasons so many projects fail. If everyone on your project team can identify with the following four statements, you're well on your way:

1. I'm empowered to do what I do best—When people have the opportunity to do what they do best, we get their best work, they're motivated and engaged—which helps them perform at a higher level. Project leaders who empower their teams to do what they do best consistently complete successful projects.
2. I have the tools to do my work right—This may or may not include your project management tool, but if the team doesn't have the right tools, their productivity drops. Have you ever wondered why the same team members who won't (or don't) update project status in their PM software, will spend a couple hours at home updating personal status on Facebook or Twitter? I have. I believe it's because the software solutions used in most organizations use software designed to provide value to project managers and stakeholders—not individual team members. And, if the only value the team sees in a new solution is a better way for management to "watch what's going on", it's not the right tool for the team. If everyone on the team (including individual contributors) can see value, project managers and other business leaders will be able to seamlessly capture all the accurate and timely project information they need to make informed decisions.
3. I'm recognized for my contributions—Most people are proud of what they do and want to feel like they are making meaningful contributions to objectives that lead to value. I'm not talking about insincere "atta-boys" but I am talking about being aware and recognizing superior performance and consistent effort. Of course there may be members of the team who refuse to step up. In those instances, I think it's important to evaluate whether or not the problem is of our creation or that particular team member just might not be right for the team. As a team member, you might be an incredibly talented and brilliant individual, but if you are unwilling to contribute your best efforts for the benefit of the team, are difficult to work with or otherwise a consistently low performer, you might not be right for the team.
4. I know what's expected of me—For team members to perform at their best, they shouldn't have to makes guesses about priorities. If they can't reliably answer the questions, "What should I be doing now?" and "What should I do next?" it's difficult to get their best efforts. It doesn't make sense to expect team members to "figure it out for themselves." That's not to say that team members need to be directed or hand-held every step of the way either, but it does mean that everyone needs to completely understand the objectives of every project, understand their own individual role and contribution to the team and have all the information they need to keep them working toward the objective. Ambiguity in this regard is a real productivity killer.

Like most things, it isn't really that complicated. Individual contributors on the team are every bit as critical as the linchpin is to the wheel and axle. When your methods and solutions consider the needs of everyone on the team, you'll foster and environment where a free-flow of timely and accurate project information is available for informing smart project decisions; and your projects will be more successful.

What are you doing to keep the wheels turning?

Any group that provides shared services within an organization must deal with project sponspors who think their project is the most important thing happening and deserve priority treatment—even if it isn't or doesn't. What's worse, in many organizations, they often go directly to individual team members to get their work done first—chewing up time that should be spent on priority projects.

This distracts team members from their primary objectives, and they struggle to manage priorities. This is not only frustrating to project leaders, who soon realize that squeaky wheels in their organizations are really directing the team—the team is frustrated too.

Although there are organizations that have an active Project Management Office (PMO) and formalized processes for evaluating and prioritizing all inbound project requests—most don't. Part of a successful project organization is effectively managing the queue of inbound projects.

Ironically, an approach that can help manage the queue can also provides project leaders with reliable information, engage the team, and create an environment where individuals can contribute at a higher level and take ownership of their work.

Regardless of how your particular organization tackles these challenges, an effective approach should include the following:

1. It Works the Way People Naturally Work—enabling stakeholders to request work, suggest deadlines, collaborate and negotiate. Whether it happens formally or informally in your organization, these negotiations are going on right now anyway—you just might not be a part of the discussion. Creating a formalized queue for how requests are submitted and distributed to the team is critical. For some teams this might mean incorporating a more social feel to how work is requested or enabling dialog and negotiation (which usually transpires when work is assigned). Forcing people to work within a "process" that doesn't feel natural will never be really effective.
2. It's Tailored to All Types of Workers—providing value to everyone on the team. For example, if the only value the team sees in a new solution is a better way for management to "watch what's going on", it won't work. However, if everyone (including individual team members) can see some value, management will be able to seamlessly collect the project information they want—at the source. I'm convinced that providing a method or solution that provides value to the individual contributors on a project team is critical to fostering an environment with a free-flow of timely and accurate project information for informing decisions.
3. It Portrays Work in Context—because projects aren't the only work people deal with every day. If project leaders and their teams don't have visibility into everything that's going on and how it interrelates, it's an incomplete picture. What's more, information about tasks, projects and goals should be captured in a way that provides context. Although I don't advocate implementing Twitter or Facebook into the process, a Twitter-like approach that attaches conversations to tasks and issues is incredibly valuable to leaders trying to make sense out of all the data collected within projects.

Over the years I've discovered that the solution to most issues I face in the workplace aren't as complicated as I originally wanted to make them. I'm a big believer in executing the most simple solution that will get the job done. The same is true with today's three keys.

If you already have a formalized process for evaluating potential projects (like Loyola's process I mentioned a few days ago) consider yourself fortunate. If not, give these tips a try. Is there anything you can add to the list?

Keeping an open and effective line of communication with stakeholders is important. A couple of years ago I stumbled on this list of tips for presenting to stakeholders, which is worth rehashing. Sometimes it seems like a thirty-minute meeting can be over in sixty seconds. Stakeholders sometimes have short attention spans, so if you don’t capture their attention in the first minute or two, they’ll start checking their email and watching the clock or worse—bail on your meeting.

Anyone involved in project-based work has to deal with sponsors and stakeholders. With that in mind, here are ten tips that might help your presentations:

1. Pique their interest: An agenda is always a good idea, but a brief summary of what will be discussed is even better. Plus, it gives stakeholders a take-away and allows them to come prepared with questions.
2. Don’t assume they know their job as stakeholder: They might understand the high-level view, but you will probably need to fill in the details.
3. Keep it simple: Give them the situation in straightforward terms. Don’t overwhelm them with information. Cut to the chase. (However, be prepared for a deeper dive if they start asking questions.)
4. Use numbers and pictures: PowerPoint is a great tool for presenting graphics and numbers to stakeholders. It’s how they present information to each other. You should too.
5. Sometimes you have to use logic: Accept the fact that there might not always be data to support a particular situation. Not having numbers to back up your position could make a successful argument problematic, so you may have to turn to "if … then …" logic to shed light on a situation. However, don’t expect the same results or response from stakeholders—numbers rule with them.
6. Waiting is never a good option: Don’t wait until a problem is obvious—it’s often more difficult to solve the issue at that point.
7. Always offer a solution: If you are going to bring up a problem without offering a potential solution, you might as well tell the stakeholders, "Fire me now." Finding solutions is part of your job as project manager.
8. Specify the actions required of them: If stakeholders need to take action, don’t assume it will be obvious to them. Restate—in list form—what actions need to be taken and when.
9. Always say "yes," but make sure they understand how much "yes" costs: Sponsors and stakeholders don’t like to be told "no," so don’t do it. Just make sure they understand the cost of their request, so they can judge for themselves whether or not "yes" is worth it.
10. Don’t stop reporting status because stakeholders stop requiring it: Perception is reality. If stakeholders perceive that you aren’t doing anything—your not. Don’t let your head be the next one on the chopping block.

Regardless of your company’s work management methodology, there are a lot of project management tools available to help manage tasks and time-lines—some will help you more effectively communicate with the stakeholders in your organization. Whether or not your chosen project management tool facilitates that kind of communication, ignoring that important part of your role as project manager is dangerous. What do you do in your organization to encourage a positive relationship with stakeholders?