PJ's Rules of Project Management

Project management is one of those weird occupations where we think we know what a "project manager" is but the specifics are all over the map.

I've seen different organizations give dramatically different levels of responsibility and authority to the "project manager". Some are responsible for tracking financial performance while others track only the requirements; some are responsible for talking to clients and stakeholders while others talk mainly to internal teams; some are responsible for planning and resource allocation while others have plans thrust upon them; and some directly lead their teams and get deep into project details, while others supervise from a distance. 

I've also seen great variation in titles for folks who essentially do the same thing. Some simply get a title of "Project Manager". Others are called "Project Coordinators" or "Project Advocates". There are "Senior" project managers, although I've never seen a consistent definition of "seniority". I've even seen "Director of Project Management" (no doubt more impressive-sounding).

Then there's the matter of credentials. We are supposed to believe that certain certification programs will make someone a better project manager for software development projects. I'm not so sure it's that simple. How about "big company" experience? Surely those "big company" project managers are especially good? I wouldn't jump to that conclusion. Sometimes they ARE good, but I've also worked with many that were used to having a "big team" to support them. Take away that big team, or put them in a position where they have to lead everyone else, and sometimes they don't know what to do.

I suppose after having spent over a decade holding various project manager positions, you could say "I have an opinion"! I think there's more to it than that, however. If you do anything long enough, you start to see the same things over and over again. You will also eventually figure out what works after you've lived through enough disasters, whether caused by you or someone else. Having gone through the school of "hard knocks" myself, in this article I'm going to offer my take on the everyday life of the "project manager", or at least my experience working for three digital agencies.

I apologize in advance to any senior executives, human resource departments, consultants, college professors, or other important people I may rankle with what may be viewed as a controversial perspective. Hopefully I will generate more agreement than disagreement--especially amongst those who have spent time in the trenches.

First, let's tackle a question we shouldn't shy away from; why do we even need a project manager in the first place? Many organizations take it for granted, but let me ask you this: why do you rarely hear the term "project manager" in Agile circles?

Take Scrum for example. They talk about a product owner, a scrum master, and a cross-functional, "self-organizing team". Some people mistakenly think that they just renamed "project manager" to "scrum master". They are NOT the same thing and are not even meant to be close. The latter is a role which, some argue, can be played by anyone or may even be needed only temporarily! Descriptions of how they differ can be easily found on the Internet, so I won't belabor that here.

What I want to focus on is the intersection where theory meets reality, and things get fuzzy. In a theoretically perfect implementation of Scrum, between the product owner, the scrum master, and the team, everything that needs to be taken care of to manage a project is taken care of. Personally, I think it's great. It's a model of collaboration that proves the point that an extra layer of "management" can be removed if people just really get involved and work closely with each other.

At least, that's how I picture it. I've never been lucky enough to work somewhere where Scrum was implemented in its totality. Rather, I'm accustomed to environments where Scrum was used in some hybrid fashion, but in otherwise conventional companies adhering to conventional business practices.

The Scrum model is often challenged, but there are always rebuttals from organizations using it successfully. Along with those rebuttals, however, is the acknowledgement that it takes the right people to make it work. I would even go so far as to say "talented people with the appropriate levels of involvement, authority, and understanding of the process".

This is not a criticism of Scrum, just a reflection on its prerequisites. I do not feel threatened by Scrum not having a position of "project manager"; on the contrary I feel that the more focused "product owner" role has the potential for greater good (and incidentally has more overlap with what project managers do). But what happens when there's no one to fill the product owner role the way it's intended? What if there are multiple stakeholders rather than a single product owner, or the person who would normally be the product owner is a remote client? What if the person who should be the product owner is otherwise busy or doesn't want to get involved in the day-to-day project? My experience is that an authentic product owner is unavailable in many real-world situations. As a result, managing the project does not become something that takes care of itself.

Enter the project manager. When the team needs direction, decisions to be made, obstacles to be removed, and gaps filled in terms of collaboration or expectations, it falls to the project manager to address. It's somewhat of a jack-of-all-trades position. As such, I see the job of the project manager as being threefold.

First, the project manager "bridges" the gap between two groups that must come to an understanding for a project to succeed. The first group are those who have a general idea that requires a technology solution but don't have the knowledge to implement it; call them the "business". The second group understands technology but doesn't have a clear picture of what the business wants and why; call them the "developers". Each group speaks a different language and has a different context, way of looking at things, and a different set of dependencies that matter. 

This can be a hard chasm to cross, and many organizations suffer from a dysfunctional or even antagonistic relationship between their teams, whether they refer to them as "business and developers", "marketing and IT", "sales and delivery", or so on. Many projects "fail" because of simple misunderstandings, wrong assumptions, or improper expectations.

As a project manager I am the "go-between"; my job is not to favor one side or the other, but to make sure the business gets the best possible support to make the project a success, AND the developers get the best possible support to make the project a success. That usually requires a significant effort.

When I first started in this business, I felt that what gave me an edge is that I have experience as former software developer and I also have a business degree and experience in marketing roles. I was able to explain technical details and software development processes in a simple way to the business, and I was able to understand the language and needs of the developers, and thus able to facilitate both sides.

I still think this is important. Any software project manager who does not have a technical background should seek to develop their technical savvy as much as possible, just as they should seek to develop their business, marketing, and communication savvy if they do not have a business background. I disagree with the claim that "the details aren't important". The details are always important, and sometimes critical. Understanding the work we manage is job #1.

It's about more than managing work, however. It's also about working with people. Project managers don't "manage people" in the conventional sense. Rather, we try, using influence and initiative, to motivate and mitigate potential "people issues" that might derail a project. And people issues, or people's behaviors, habits, and expectations, or the lack of the right people, or people not doing what they need to do, or not being on the same page as others--this is what makes or breaks projects. It's why projects are so difficult. Time and again, I've seen the same issues play out on projects:

• Those who know what the requirements are don't understand how to convey them to the development team in a specific enough way...

• There's no business analyst/QA team etc. to do some of the needed project "grunt work" so somebody has to pick up the slack...

• Decisions are made slowly by the stakeholders, putting project timelines in jeopardy...

• People have competing agendas for what they want out of the project and it causes the scope to mushroom out of control...

• Needed project staff is unavailable, quits unexpectedly, or is even snatched away by a competing group inside a company...

• Commitments are made without consultation, resulting in impossible deadlines or deliverables...

This is just the tip of the iceberg. I'm pretty sure many project managers out there will recognize these scenarios as "another day at the office".

Thus, the second job of the project manager is to deliver the project in spite of these and other challenges. It requires patience, grit, and a positive attitude, but, as one of my old mentors use to put it, "the job of the project manager is make the project easier for everyone." When you think about it this way, it's really hard to define "project manager" as a bullet list of responsibilities. Making the project easier for stakeholders and developers alike sometimes means that going the "extra mile" is the norm, by sending reminders, giving explanations, creating project artifacts, organizing materials, doing research, going on food runs--basically whatever it takes to help people get the mission accomplished. A big "thumbs up" to those that follow in these footsteps.

This brings me to the third job of the project manager: being a leader. Usually nobody on a project actually "reports" to a project manager; nor are they even in the formal chain of command, and they might not even have any "real" authority. Yet to drive the project forward they must take leadership and they must get people to follow their lead. 

It's important not to misinterpret what this means. I've seen situations where project managers tried to enforce "top-down" leadership that only resulted in themselves and their teams becoming very frustrated. As I explained in What Agile Software Development Really Means, that's not how software development works. The understanding of how best to implement the software solution is at the bottom, not at the top. Leadership in this capacity is not necessarily directing your developers, but rather listening to them, communicating their needs to the clients and stakeholders, escalating on their behalf, and coaching them to self-organize effectively. I've seen plenty of project disasters that could have been averted had someone paid attention to what the developers were saying. 

The more salient leadership a project manager provides is to effectively navigate the development process itself. This is the "specialized knowledge" I feel a project manager must bring to the table. They must know how to elicit requirements thorough enough to develop, how to estimate quickly without underestimating, how to plan a project without missing major tasks and dependencies, how to build and test software for quality and performance, how to explain the facts and negotiate with stakeholders who have unreasonable or unrealistic expectations--and more. It's significant work; and it seems no matter how many times I engage in it it, I always learn something new. Fortunately for me, I already have a great interest and fascination in everything related to software development (if this website is any indication). I would hope that anyone else who wants to be in this role would share a similar sentiment.

But enough on philosophy. I've always felt I should have something to show for all the time I've devoted to this profession. To that end, I'd like to offer a list of project management "rules" based on my experience that I hope may be useful to the next generation of project managers. I call them "PJ's Rules of Project Management", not to advertise myself as some type of guru or authority, but to just to underscore that they reflect my perspective. Specifically, it's the perspective of a guy who has, at some point, done everything wrong that you can possibly do wrong, but with trial and effort, managed to figure out a few principles worth hanging on to. Here they are:

1. Never Assume.

If you don't know for sure how something technical works, what its capabilities and limitations are, or how to create it and the effort in doing so--then don't make assumptions. The odds of being wrong are not only high, it's possible to be way off the mark. This might sound obvious, but I see it happen all the time.

Despite being non-technical, I've seen stakeholders routinely make technical assumptions that have gotten projects into more trouble than anything else I can think of. It gets really bad when someone makes an assumption AND a commitment at the same time. "I'm sure we can do that, we'll have it done by the end of the week". When the development team finds out, and points out the commitment as being grossly unrealistic  or even impossible, it's too late. The only "solution" is to work a lot of overtime in a desperate bid to save face and somehow achieve the goal. Not recommended if you don't want to burn out and lose your developers. The little bit of extra time it takes to verify or vet something is a substantially better deal. 

2. Don't Plan on Things Going 100% Right. 

"The schedule looks tight, but I think we can make it." Whenever I hear a statement like this, alarms flash through my mind. Often the circumstances around it are a) the timing is really aggressive and b) the person making the statement has a "best case scenario" playing out in their mind. Inevitably, the "best case" is more theoretical than real, which is why most projects run late.

This is incredibly common because of a psychological trap, a human peccadillo if you will. It's been researched and proven so thoroughly that scientists even have a name for it: planning fallacy. We all have a built-in tendency to underestimate because we have an easier time picturing the "orderly knowns" than the "disorderly unknowns". We gain a false sense of confidence because we know how to create project plans, SDLCs, critical paths, workflow maps, or whatever other academic tool we use to show everyone we are in command of a project. Then life happens. Somebody gets sick. You don't get the feedback you needed fast enough. Something gets stuck in legal approval. Your hard drive crashes. Somebody misinterpreted the requirements. A showstopper bug is discovered and nobody knows how to fix it. The stakeholders give you more revisions than you were expecting. The list is endless.

I sometimes see project managers stress about how to run a "perfect" project. Here's the secret: there are no perfect projects. Every project is imperfect, if not downright rocky, in some way. There is always something that doesn't go according to plan, or that nobody was expecting. People will mistakes, despite your fervent wish that they wouldn't. If you don't expect everything to go right, your project planning will improve tremendously. Pay detailed attention to everything that happens on actual projects, and you'll likely realize that you need a bigger buffer than you thought you did. Once you have that, you can focus on re-planning, remediating, and recovering rather than panicking because of the way things play out.

3. If You're Not Ahead of Schedule, You're Behind.

This follows on the heels of the last rule. The words "on track" are used liberally in project management, but it is often used in a deceptive way. Not intentionally, of course; the problem is that there is great pressure to say the project is "on track". If there's still a chance we can make the deadline, we don't want to say the project is "off track", right? Why cause needless panic or rebuke if it looks like we can make it. The problem is that many times this assessment is made when our aforementioned "buffer" is already exhausted, particularly towards the end of the project.

This is the worst time for wishful thinking, however. It is precisely at the end when we discover that "getting to done" is more trouble than we thought. That's when we find that troublesome bug, or realize on review that some important detail was missed, or get that last minute revision we were hoping we wouldn't get. Now you're hopelessly "off track".

I've seen many projects go from "green" to "red" overnight because of this phenomenon. Another way of expressing this is, "you've got to be ahead of schedule to be on time." IF (and it's a big "if"), everything does go perfectly, the worst that will happen by measuring progress this way is actually finishing ahead of time (still a winning scenario). It's more likely that it will look like you're ahead of schedule, but somehow (trust me), things will catch up and you'll end up being merely on time (which is what we wanted all along). Maintain space for "contingencies" at all times, and especially at the end.

4. If It Can Come Back To Bite You, It Will.

This is essentially "Murphy's Law", which tends to not be appreciated until it actually strikes. Again, it's psychological, because we feel overly optimistic or underrate risk when we feel we can't spare the time or the effort to do something. First there's the "Probably nothing will happen" line of thinking. This justification is given for indulging in all sorts of shortcuts and lapses in discipline. There's always many convincing reasons why we can't get around to fixing a potential issue right now. Those tend to fly out the window once the website has been hacked, the data has been lost, the server crashes beyond repair, and the backup tapes are found to be empty because we forgot to check if they are working. I wish I was exaggerating, but I have seen all of these scenarios happen first-hand, regardless of how "improbable" they seemed. Then there's the "Surely that won't be an issue" line of thinking. This crime of assumption happens when we don't feel it's necessary to do further research. I've seen dumbfounded stakeholders experience great dismay when they find out the platform, tool, API, or technology they thought was going to save the day actually doesn't do what they thought it was going to do. Suddenly the question of "Why didn't we do our homework up front?" becomes a good one. Is there a cost to mitigating all these risks? Yes, but you can afford it, even if it hurts. What you can't afford is the cost of something coming back to get you later. The price of remediation is often far, far higher than the price of prevention. It's better to pay up front.

5. Whatever is Not Made a Pressing Issue Will Be Ignored as Long as Possible.

Giving people an opportunity to procrastinate generally results in--procrastination. It's partly human nature, but it's also a survival reflex. Most of us have too many things competing for our attention, and are trying to juggle multiple priorities. We look for things to ignore so we can focus. That means whatever is not immediately due will be put off, maybe even forgotten. If it's not being asked for directly, people may assume it's not important after all. If people don't see you asking repeatedly, they may even assume it's not important any more (after all, it's been a while since you last asked). If there's anything unclear about what's being asked for, that's another reason to shelve it (the need for extra mental processing means getting put in the "later" file). Finally, if it's not clear who is responsible for what, people will assume "someone else" will take care of it.

This might sound cynical, but it's not. It's just what tends to happen because we all have too many distractions, and we should not take it personally. What we should do however, is gently but firmly make sure we're getting through the noise. Make sure everyone involved with the project knows what their "pressing issues" are at all times. Keeping things clear, simple, and to the point tends to work better than elaborate write-ups and lengthy discussions. Priorities, expectations, and timing should always be communicated. Expect to follow-up and give reminders. Most importantly, maintain a sense of urgency and a clear path forward--that's what drives people to action.

6. Momentum is Everything.

Getting people to act in the moment is great, but it's building momentum and sustaining it that is key. You want to know what a true "project killer" is? Frequent starts and stops. It's easy to fall into this pattern. What happens is the development team tries to get started on the project but only gets so far before they run into a roadblock. They get to some part of the requirements that is missing or unclear. They need to insert the copy and images but they aren't ready yet. They need a quick decision but have to wait for it be addressed. They need access to something and it takes a while to be provisioned. There are innumerable reasons, but the result is that progress comes to halt. The team turns to something else while they're waiting. Eventually they are "unblocked", but now they have to ramp back up, figure out where they left off, and try to get into the "zone" again. Let's say a task normally takes 10 hours. It's certain to take longer than that if you have to start and stop one time during the task. If you have to start and stop multiple times during the task, don't be surprised if you end up doubling the amount of time spent! This is one reason why project estimates get blown out of the water. Prepare accordingly.

Slow starts are another problem. A project that starts slowly tends to retain a lackadaisical momentum throughout. On the other hand, a strong start sets up a good pace for the entire project. At one agency I worked for, we would do significant research before we arrived at a client site to kick-off a project. We would even prepare comps in advance (even before the project was finalized). Instead of being a wasted effort, this would often kick a project into high gear, since we had something for people to react to and refine from the get-go (vs. kicking off the project by just having a discussion about what was wanted). We would set specific turnaround times for project materials and decisions, but we would also advance our own "proposal" for how we would proceed if we didn't hear back in time. I found this helped quite a bit, because it was easier for people to react to a proposed idea than to develop one from scratch; and the "threat" of moving forward with something people didn't agree with tended to spur them to action! Whether or not you go this route, I recommend giving thought on how to avoid a laggy start, hiccuping in the middle, or fizzling out at the end, which at best will run you late and over budget, and at worst will mire you in a seemingly "never-ending project" (the theme song to which is sung like that of the "Never Ending Story").  

7. Clarify Expectations.

Many wise folk have pointed out that good project management is about "managing expectations". They couldn't be more right. It's absolutely possible to get a project done on time, on-budget, and to deliver exactly according to the client's specifications--and for them to still not be happy. That concept might throw you for a loop until you actually experience it. The fact is, if there is even one important stakeholder who has some key expectation that wasn't fulfilled, the disappointment can cast a pall on the rest of the project, fairly or unfairly.

Make sure you know what people on the project are expecting, and which expectations are most critical. The mistake is to think this is intuitive. It's not. I find I often have to ask many probing questions before it's finally revealed to me what people are really expecting. It might be something completely different from the requirements they gave me! Frequently what you can practically deliver is at least slightly different, and sometime significantly different, from what they are expecting or hoping for. The quicker you can identify this, and the quicker you can re-align people and get expectations on the same page, the better. The longer the delay before a mismatch in expectations is discovered, the more it becomes a surprise or a disappointment which can derail a project that is otherwise "seemingly" going well .

8. Keep an Eye on the Details.

My feeling is that a project manager should know everything that is going on with their project at all times. If anyone should be keeping this much of an eye on the project, who else would it be? I am always surprised to see project managers who manage their project at "arms length", so to speak. They sort of try to put the project on "auto-pilot", put it to the rest of the team to carry on the "process", and just make themselves available for escalations. So far, I've always seen this hands-off approach result in project upsets of some type or another.

Sometimes, on post-mortem, I actually have to talk to the developers to find out what happened, because the "project manager" doesn't really have a clear explanation. That's backwards. In such situations, by the time something gets "escalated" to the project manager, it's usually too late to do much about it. It's a real travesty if it's only then that the project manager tries to figure out what's been going on.

The project manager must get into the thick of the fray. That means understanding the project backwards and forwards, including understanding the requirements, the mechanics of the solution, and all the little "gotchas" and dependencies that need to be communicated. He or she must keep track of how long work has been taking, and use this information to actively forecast how much more time is needed (rather then being surprised that the project is late). Most critically, the project manager must "keep the ship steady", not simply by setting a direction, but by making many small adjustments along the way, when and where needed.

This entails not just tracking the project parameters and metrics, but also having a solid relationship with team members and stakeholders. For those you interact with on a daily basis (which should be most everyone), do you know their likes and dislikes, strengths and weaknesses, desires and expectations, communication and thinking styles? Are you making an effort to learn? I've always found this to be even more important than my knowledge of the software development process, or my skills with Microsoft Project and Excel. I always strive to know what my developers are thinking and for them to know what I am thinking. As a former developer, I know it takes great attention to detail to write a well-functioning application. As a project manager, I find it takes a similar, but even more comprehensive, attention to detail to shepherd a well-functioning project. 

9. Prioritize Quality at Every Step.

One of the surest ways to get into trouble in this business is to take shortcuts on quality. I explained why this is such a key issue in What Agile Software Development Really Means; to summarize, to increase productivity we must increase efficiency, and long-term efficiency is driven by quality. 

This means finding quality people to be on the team, providing a quality working environment, building a quality infrastructure and software architecture, enforcing quality development practices, and quality in testing. Most organizations, unfortunately, skimp in one or more of these areas. This is one of the worst areas, however, to implement "cost cutting".

First, it takes quality developers to care about and deliver quality. Period. If quality (which ultimately equals productivity) is important, hiring and retaining the best talent possible should be a no-brainer.  Second, shortcuts in quality should not be encouraged for the sake of reduced cost and delivery time. This leads to technical debt, the inertia of which will reduce efficiency the more time passes, as well as increase the cost of the change.

Building a sloppy software architecture is a classic example. This happens all the time under the noses of oblivious stakeholders, often to meet aggressive deadlines or because the developers are amateur. On the outside, everything looks fine, and the application meets the requirements. But, like a poorly built house, the cracks begin to show as soon as the application is truly tested. Perhaps a modification is needed, or an additional feature needs to be added, or an expansion or integration. That is when quality counts, because there is a vast difference between "good code" and "bad code". Good code takes more time, care, and skill to produce, but results in applications that can grow and change without a lot of undue effort. Bad code, on the other hand, tends to fall apart when you try to change it, resulting in many bugs, or requiring massive retooling in order to modify. Cutting quality thus results in a "vicious cycle" where change becomes increasingly difficult, speed and productivity steadily decreases, and deliverables become less and less impressive. I've seen chain reactions where quality cuts ultimately led to massive layoffs and even shutting down IT departments altogether because of the backslide. The lesson is clear; in everything you do, insist on quality!

10. Know When to Push Back.

There are times, when for the good of the project or the team, you need to stand your ground or voice your disagreement, and not doing so, regardless of how expedient it may be, is not in everyone's best interests.

This does not mean that you have to be belligerent or even that you will come across that way. Unfortunately, I've seen cases where project managers are afraid to say something that might "seem" contentious or disagreeable to a client or superior even if they feel otherwise. This is a disservice to everyone. A project manager's thinking must be beyond this, if they are really to fulfill the promise of their role.

That promise is this: to be the project's guardian. What I mean by that is that you have to protect everything that needs protecting in order for the project to succeed. What first comes to mind is protecting the team. To perform at its best, you have to protect the team from stress and burnout. This is easier said than done, because stakeholders often give tall demands and short deadlines. If nobody is there to negotiate the workload down into something reasonable and sustainable, the development team gets the short end of the stick. It makes me sad to think that in some places developers are regularly working 60-80 hour weeks, and are "churned and burned" in order to meet requirements. Overworking and eventually losing your best assets (i.e. your talent) is folly, not bravado. It also erodes your leadership and your ability to build a team, upon which everything else is predicated.

In contrast, a project manager needs to look for whatever he can do to make his or team better performing. That might mean many things; reducing an oppressive workload, finding more interesting work, taking a break to boost morale, adjusting someone's responsibilities, getting the team new software or computer equipment, etc. Of course there are times when the team has to "buckle" down and deal with extra hours or some other hardship to get through a troublesome project; but you must look out for the team first for them to return the favor when you need it.

A project manager must also protect the clients and stakeholders. From who?Themselves, mostly. I know that stakeholders don't mean to be unreasonable; they just don't understand what to expect most of the time, or the consequences. The project manager must explain all that, while finding a way to accomplish the objectives the stakeholder has in mind. The problem with merely "giving in" to everything the client wants is that what they think they want may not be what they really need. Often I find myself talking clients out of ideas that are overly complicated, have a bad user experience, or are not the best technical solutions. I'm not saying "no"; I'm trying to show them a better way to do it, and I explain why. Sometimes a little "creative problem solving" is needed, but in the end the client is usually grateful I pushed back and gave them a better, less risky, or more practical alternative.

Finally, a project manager must protect the vision of the project. Projects tend to be pushed and pulled in various ways as they're worked on. The scope increases as people think of additional features they want to include. The complexity increases as people decide to make things more sophisticated. We spend too much time working on edge cases and "window dressings". All of these--and more--need to be reigned in to maintain focus on the original objectives of the project. This means asking of every proposal that comes along: how is this increasing the return on investment? How is this increasing sales? How is it increasing customer retention? How is it adding business value? How is it achieving what we set out to achieve with this project? We must actively bear in mind the two or three things that matter most, the 20% that drives 80% of the results, and that the "perfect" is the enemy of the "good"--and push back on peripheral distractions.

11. Set the Tone. 

Humans are emotional creatures, and it can really come out on projects, simply because a lot of people must cooperate and coordinate with each other, and that is inherently challenging. There are bound to be misunderstandings and disagreements. Sometimes people get frustrated, accusatory, defensive, political, resentful, or exhibit other behaviors which adds drama to the project. For better or worse, it's part of the game.

As a project manager you tend to be right in the center, which positions you to be either a moderating or enabling influence. Personally, I hate drama, so my vote is to act as a moderating influence. That requires patience and being able to keep your ego in check. You have to be willing to let people vent their frustration but then help bring them back to a constructive, problem-solving mood, even when you're the one being yelled at. A good attitude is everything. Once you've let negativity into the project it will spread like a plague and drag everyone down. Sometimes I feel challenged as well, but I try to remind myself that my reaction influences everyone else, and I try to focus on the positive and doing something constructive other than worrying, complaining, or being upset. Focusing on what needs to be done is often a good remedy.

Another way a project manager sets the tone is by their example. I don't believe in the "do as I say and not as I do" philosophy. If you want people to be organized and efficient, for example, you should be organized and efficient yourself. If you want them to be open with you, then you must speak openly with them. If you want things done a certain way, it's better to show it than to just talk about it. And so on. When I run meetings, for example, I take care to have my agenda and presentation materials prepared, to start on time, and to stay on point. This is because if I have to attend meetings, I want people to do the same for me (I'm not a fan of wandering, pointless meetings). Everything you do sets an example of some sort. To tell someone to follow a standard that you visibly don't adhere to yourself is more likely to create a subtle disrespect than a following.  If you want to lead without formal authority--which is what project management is--one of the most effective approaches I know is to lead by example.  

12. Keep it in Perspective. 

Don't misunderstand this discussion as one about various ways to "control" the outcome of a project. It's not. You can try to influence a project to the best of your ability, but ultimately you can't "control" it anymore than you can control anything in life.

At the end of the day, all we can do is try our best. Sometimes our efforts pay off, the project goes swimmingly, and we are recognized for our contribution. Other times, we get the blame for a situation that was not our doing. Still others, we are taken for granted even though we bent over backwards to save the project from utter ruin. Occasionally we may even feel we were undermined by certain people on the project.

It's important to not get too wrapped up in these things. This may be a reflection of a Stoic philosophy on my part, but I try to keep my focus on doing my best and providing good service--those are the things I can control. This is also what I take my satisfaction from--that and the support of the team I try to build. If I or someone else commits a blunder, I acknowledge it, learn from it, get back on the wagon, and try not to repeat it, without dwelling on it. Heck, I've even broken or forgotten to apply my own "rules" on more than one occasion (and lived to regret it). Don't beat yourself up for being human, and recognize that other people are human too, and will react and behave accordingly. A few months from now, all the details, urgencies, and stresses of the moment will be little more than a vague memory. What people actually remember are things like your responsiveness, attitude, honesty, and your initiative to help others--good things to stand on no matter your occupation!

Conclusion

There it is: my two cents on project management. Here are the rules summarized:

1. Never Assume.

2. Don't Plan on Things Going 100% Right.

3. If You're Not Ahead of Schedule, You're Behind.

4. If It Can Come Back to Bite You, It Will.

5. Whatever is Not Made a Pressing Issue Will Be Ignored as Long as Possible.

6. Momentum is Everything.

7. Clarify Expectations.

8. Keep an Eye on the Details.

9. Prioritize Quality at Every Step.

10. Know When to Push Back.

11. Set the Tone.

12. Keep it in Perspective.

It was helpful to me just to put some of my own thoughts on paper, but I hope this was also insightful to any new or aspiring project managers, to anyone who hires or works with project managers, or even to seasoned project managers who found this interesting. To all who proudly stand in the shoes of this profession: I salute you!