PM Articles > Kent McDonald > Letter to Me

Letter to Me

Reflecting on my 15-year career of project work, I am struck by how many new project managers learn the same hard lessons I did in the same way—through painful experience. That thought had been floating around the back of my head not really going anywhere until about a week ago, when I was driving my six-year-old daughter to school and Brad Paisley's song Letter to Me came on the radio.

For those of you not familiar with the song, it's about someone my age writing to his 17-year-old self about all the things he knows now and wishes he had known or done then. It occurred to me that perhaps people have to learn these lessons the hard way because they did not have someone they trust sharing their own experiences and providing advice. While this is a task tailor-made for a good mentor, a satisfactory substitute would be some kind of communication from their older and (hopefully wiser) selves sharing their experiences.

Putting aside for a minute the niggling details about the whole space-time continuum and tying a proverbial knot in a given timeline, it seemed like an idea worth exploring. So here is my letter to my younger self, just starting out in my project management career.

Hey Kent,

Congratulations on getting that new Project Management gig. I'd wish you good luck, but I have it on pretty good authority that you had some good breaks and some bad breaks along the way, so the wish of good luck is more a social nicety than anything of any real substance.

If you haven't figured it out already, this is you 15 years from now. I thought I'd drop you a line to give you some advice to make your project management work easier. This is probably an exercise in futility, because you will most likely read this, appreciate the heads up, and then do half the things I suggest you don't do. I know that, because that's what I did. Sometimes you just have to learn things the hard way. That aside, here is a list of my things I wish I knew when I was your age:

Things are not as simple as they seem.
You're not in college any more (although you're closer to it than I am, and you are really going to enjoy that executive MBA program). Except for dynamics and those nasty differential equations, college was a lot more straightforward than real life. There were problems you had to solve in your classes, but you always seemed to have all the information you needed. Project Management is not like that. You will find that you are missing a lot of information and will have to make a lot of assumptions. If there's any way to avoid making those assumptions, do it. If you are not sure, ask. If you must make assumptions, make sure you note them as such and then set up the project to verify or falsify those assumptions as soon as you can. It's ok if you make an incorrect assumption as long as you can identify it as false and correct your plans.

Don't overcomplicate things.
Since things aren't nearly as simple as they initially seem, the last thing you want to do is make them more complicated. Don't fall into the trip of thinking you have to design a solution that handles EVERY exception systematically. You can address problems with complicated logic built into the system, or you can allow the people using the system to apply logic and do some thinking for themselves. The same goes for the method used on the project. Provide your team with some simple rules and let them take it from there.

Plans are useless, planning is indispensable.
You'll figure out after the first couple of projects that there are lot of subtleties to project management, and this is one of the keys. You'll hear a lot of people talk about creating a project plan and developing a project schedule. You'll also roll your eyes at the discussions that seem to go on incessantly about why a plan and a schedule are not synonymous and that a project plan is much more than just a list of what things you are doing when. The main thing to remember throughout all of this is that the act of planning is a lot more valuable than the resulting document, be it a plan or a schedule.

The purpose of the planning exercise is not to generate a Microsoft Project schedule, but to gain agreement on how the team is going to work together, what things people have to do, and by when they have to do it. The discussions that occur during that planning work are key because they will point out risks and constraints that may not have surfaced otherwise. Documenting the key points from these discussions, i.e. "the plan," is important because it captures what agreements the team made for future reference.

It is not your job to be everyone's friend.
If you are working on any project that is truly worth doing, it will mean that you are making some substantial changes to the organization, which will also mean that you are rocking someone's world, moving someone's cheese, throwing someone's fish, or whatever cutesy change management book is the rage at the time. Simply put, you will have to deal with people's attitudes toward change. Don't take their reactions personally; that will drive you nuts. You have to assume that everyone is trying to do what they think is right from their point of view. The trouble is that their point of view may be that the way they have always done it is the right way. Try to understand your stakeholders' perspective and gain some level of understanding of how the project looks from their perspective. Then consider what you can do help all of your stakeholders see the benefits to their work as a result of the project.

Understand the true purpose of change management.
Change happens a lot on projects. In fact, projects exist to introduce a change of some sort. Change Management processes are built to handle this frequency of change. Managing change does not mean instilling a change prevention process with a 6-page change request form in triplicate and three levels of management approval in order to correct a grammatical error on a project document. (Don't worry, you won't introduce such an arcane process, but you will experience a few.) Managing change means making sure that everyone that needs to know about a change does know about it as soon as the appropriate decision maker decides the change should occur. In other words, just because you update a requirements document does not mean that the entire team—especially developers and testers—are going to magically know that a change occurred.

The other thing to remember is that there are difference kinds of change, especially when you are dealing with requirements. As you dive into more detail, a lot of what some people will want to label as "change in requirements" is really just a clearer understanding. Make sure you are able to tell the difference and structure your approach to take advantage of learning opportunities.

Know who the real decision maker is, and help them out.
You will find that the projects in which you have an active, engaged Project Sponsor with the authority and willingness to make decisions for that project are the projects most likely to succeed. Make sure your project sponsor has some skin in the game—preferably they will own the result after the project is completed. Expect this Project Sponsor to make key project-level decisions, and be prepared to help them by providing the information—all the information—they need to make timely, effective decisions.

Along with that, make sure you communicate accurate status on a regular basis to your project sponsor and other stakeholders. Although you'll be tempted to hide or sugarcoat bad news, withholding information is rarely the right course of action. The truth will come out eventually, and very few people like surprises, especially when they are unpleasant. Remember, bad news is not like fine wine—it does not get better with age.

Well, just a few hints from me to you. Hope you follow them. Then again, thinking about that whole space-time continuum thing and the idea about not messing with the past, I suspect you won't, because otherwise I wouldn't have had the experience to write this letter.



More Great Advice
Alfonso Bucero once reflected on the scattered focus of his younger self, with some advice for being more effective. Carl Pritchard encouraged a more positive outlook after listening to the Dalai Lama and Mr. Rogers. Our New Project Manager Fast Track includes advice on what matters most when it's time to plan and schedule a project.

What advice would you give yourself as a new project manager? Share your Letter to Me in the comments below.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Define the project reporting requirements in the charter, and stick to them - even if your project sponsor never reads your reports! The process is more important to you than to anyone else. It is an important forcing function that makes you put aside the current hot issues of the day and focus on the big picture. It is always tempting to put off the status reports in favor of putting out fires. Do not succumb to the temptation!

Dear Kent,

We all wish at some point especially when things go wrong, that we could go back in time and do things differently to obtain the desired results. However we never seem to learn from other's mistakes.
It is said that "failures are stepping stones to success"; true but these failures need not be our own. We have loads of guidelines from our predecessors which we as humans simply choose to ignore.
Anyway, your idea of writing to oneself is very thoughtful; we all do it in our minds but writing it down makes it more effective I guess. Good work.

Kind regards, Ignatius

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.