Over the last decade or so I have been managing or participated in quite a few projects, from very small server builds to fortune 500 company global network rebuilds. The nice thing about that is that not only you get to experience what works, but also what doesn't, and why. One thing that certainly has helped project management in IT become mature over the last few years is Prince2. Don't worry, I don't intend to make this yet another Prince2 cheering article. I'm mentioning it because I believe it is a good approach, but I also believe there's more. Some project managers seem to have lost sight of all the other factors that make a project successful, while focusing too much on going through the motions of Prince2. It is important to keep overview of the big picture and realize that Prince2 is only a part of that. Good IT project managers are hard to find, they need to have a very broad skill set, be meticulous, have great personal and social skills, have a good memory, be patient, know how to be a leader, be knowledgeable, and at times know when to suppress their ego. The list goes on and on. As mentioned; all of this has nothing to do with Prince2.

Besides personal skills and a sound methodology, there are a few more things that I find to be invaluable in leading a project to a successful conclusion. They are are expectation management and communication. Two area's that aren't as 'hard' and measurable as you might want in project management land, but nevertheless key elements in successful project management, and quite often not taken seriously enough.

I came across this ship some time ago, to nice a name to let go ;-)

As you may have guessed 'Prins' is Prince in Dutch.

Expectation management

Expectation management is one of the most important things to keep in mind throughout the project. It needs to be targeted at the different groups of people that are associated with the project; the project board (the 'customer'), the end users and the project participants (the team). They all expect something from the project, ranging from nothing to too much. Your job is to control these expectations; your most important tools are planning and communication. It all starts at how good you and your project team understand the project scope and goals. (I'm conveniently assuming that the business case paperwork was created and approved) That's why Prince2 has the project mandate, project brief and the process of getting these approved by the project board. This is a very important phase of the project, and it is right at the start. If the project manager underestimates the importance of it and just goes through the Prince2 motions the consequences could very well be a failed project. The reason is simple; if you do not have a good grasp of what the project requirements are, you do not have a full understanding of what needs to be done to get there. Ergo: you cannot manage any expectations if you yourself do not have a sound understanding of the project and its expectations. Prince2 helps you by requiring a project brief, based on the project mandate. A good approach is to gather as much information about the project goals and expectations and document that as clearly as possible. Then go trough this document together with the project board and mirror to them what your understanding of their requirements are. If possible simplify the project goals and scope into understandable chunks (but make no omissions!). Make sure to use pictures and diagrams to emphasize or help explain your points, remember that typically you're dealing with higher management who may have a short attention span for these type of things or limited time, and do not appreciate being bothered with techno-speak. For you however it is vitally important at this phase that you get your points across and that there is a good understanding at management level of your interpretation of the project. If anywhere, this phase of the project calls for the KISS principle. If after this session the project board approves the project brief that contains this information, the same documentation can be used in meetings with the project team to further discuss the expectations and take the planning to the next level.

If this project was initiated for a customer, this often means there was a sales path before it landed on your desk. What promises were made? What time and budget constraints were discussed? This is where you start; first thing you need to do is get a good hand-over from the sales lead. (if this is a sales related project). Unfortunately sales people typically aren't 'project management aware' (yes, that's a euphemism) and some scenarios in my past reminded me of Dilbert…If this is the situation you find yourself in, feel free to translate the previously mentioned 'hand-over' into 'damage control'. In defense of the sales people: of course there is something to say for getting the project sales-wise, but it is up to the project manager and sales team to come up with certain agreements about what limits never to cross in getting a deal. Especially in projects that take longer, costs can build up over time. In these scenario's it vitally important not to go 'all-overboard' to get the deal. In fact, experience learns it is sometimes better (in terms of budget or stress) to let an opportunity pass rather than to start with incorrect expectations. If this doesn't happen it is the sales person who gets the bonus for getting the deal, and it's you –and the customer!- who need to clean up the mess.

The tricky part about all this is: at the start of a project it's usually very hard to oversee what exactly needs to happen, how much things will cost and how long it will take. Obviously this makes it very hard to manage expectations! If you as project manager do not know what exactly is going to happen, how can you communicate that to others? In fact; that's exactly what you communicate. At the start of the project nobody expects you to understand all the details yet, only after the PID (Project Initiation Document) and project Brief have been made it is safe to assume there's a decent idea about most of the details of the project. And any project manager with a little experience will be able to tell you that even then there will be unexpected problems that will take time money and resources beyond the scope of the project. Each type of project will have its risks, and it is wise to try to estimate how 'tricky' a project will be and allow for the project planning and budget to size to meet those risks. Of course the project board needs to be aware of this, and the perfect place to communicate this is handed to you in Prince2's risk management. In light of the previous paragraph: be careful when managing expectations, always allow for some room to change your planning.

Besides the project board/customer there are also expectations within your team. The team members need to know exactly what is needed from them and when to deliver. That's why the planning is done. I often see this go wrong where team members seem to think the planning is made for their convenience, and time and time again do not deliver their targets on time, so that the planning needs to be adjusted with all the consequences this has for future phases and parts of the project. The trick here is to manage expectations to provide a clear structure of what is needed from the team members. This goes as far as when to hold meetings, what is discussed when and how in the meetings (I'll get back to this) and even taking (if possible) action with team members that do not perform. Do you want someone in your team who drags down the whole project?

Then of course there's the 'end user' of the project. It's a good idea to keep them in the loop of the 'big events' when going through the project (depending on the project size and impact on this demographic), but be aware of them getting tired of constant updates, to the point that you're constant stream of E-Mails is being ignored. Keeping that in mind, it is usually a good idea to start managing their expectations near the end of the project when things are close to completion. You'll have a much better idea of the target date and the impact on the end user, and you will have a better understanding of the end user population, helping you figure out how to approach them best. Pilots and training programs typically are well responded upon.

After reading this chapter, make sure to take this with you: You can manage a project to close to perfection, within budget, time and project scope. However if you have not managed expectations well (especially the end-users) you may just as well consider the project failed.

Communication

A lot of the expectation management goes hand in hand with the subject of this chapter: communication. A so called 'soft-skill' that IT people are supposed to be bad at, if you are to believe the stereotypes. I believe a lot of great technical blogs on the internet to prove the opposite ;-) What I do see however is that we 'techies' tend to use our tools too often and misjudge the impact of it on the audience. I'm talking about E-Mail. Don't get me wrong! I love E-mail (well.. mostly) but I also believe it is being seriously mis/over-used, and I'm not referring to spam. I also believe that it is a bad tool for communication if you –really- want your message to come across with a large audience. Contrary to what you might want to think: usually most end-users just don't care as much about your project as you do. Some could care less! Getting these people's attention by sending a two page E-Mail addressed to 'all' two months before the project starts impacting them, may well be the worst thing to do. Try more original things! Hang up posters at the cafeteria, speak to the department managers and ask them to relay the message. Get the CEO to reference your project (and internal webs-site/webpage) at the quarterly speech. (depending on the size of the project of course). Make flyers and put them on people desks. Put up a sign and hang it up over the parking lot. I'll stop here, I'm sure you're getting it. In fact, coming up with interesting ways to communicate your message can be a fun exercise for a team meeting.

And that gives me a nice bridge to the next level of communication: within the team. If anything, try to make team meetings structured. And with structured I mean: according to schedule, preferably horizontally programmed: For example weekly at 10:00 AM. Don't plan them at the end of the week or day, when people do not tend to get the best ideas. In addition, make sure people understand you expectations (sound familiar) with regards to what the meeting will look like. Make sure people understand they need to be there on time and ready to start at the time agreed upon. Especially at the start some people with try and show up 5 to 10 minutes late. This is especially annoying if you're working with an international team, and meetings need to be over the phone of video-system. Besides that, take a moment and calculate the costs of 10 team members (usually valuable employees of the company) doing nothing, waiting for one tardy project member. Once everybody is there start the meeting by telling everybody what you expect this meeting to be like: for example "we'll start by going through the meeting minutes of the last meeting and see where we are with the targets from last week, then we'll discuss the progress of the overall progress of the project and where we are, then we'll assign targets for the next phases and then we'll have a short brainstorming session about X." "I expect the meeting to take 1 hour and 15 minutes". This gives structure to the meeting, and now you have a tool to interrupt people who like to hear themselves talk. It helps you to organize 'smooth' meetings that don't take too long, and people respond well to that.

It is very important to make clear that you expect to get something out of this meeting. This is as simple as mentioning at the start of the meeting what you would like to get out of it: "The objective for this meeting is: 1. Setting a timeline for the project (for example), 2. Getting a decision on X,Y and Z". The worst meetings I have been in are the endless brainstorm sessions where nobody takes responsibility for an objective, but everybody has the greatest ideas and loves to go on and on about it explaining to the audience how smart they are. At the end of the meeting no decisions have been made and nobody has been given a target and timeline. At the start of the project these brainstorm sessions may be valuable to pick people brains, but make sure to stop this once the project starts gaining momentum and brainstorming may have become less important.

If your team is larger (typically more than 5 people) ask yourself if everybody really needs to be there. Your project plan can tell you what persons or teams you will need in the time to come so only get these people involved. Your meetings should not be 'one-to-many' meetings just to keep everyone up to date of the latest status, and if people do not have any direct short term responsibility they will feel like they are wasting time. That's why meeting minutes have been invented; it is your responsibility to make sure people are aware of the status, but don't use your project meetings to take these people 'hostage' with your updates when they have no direct impact on the meeting at that time. If the type of project dictates everybody to be fully aware of the latest changes you might want to consider splitting the meeting in two parts, where you start with the updates, allow people to leave if they have no further business and continue with the 'skeleton team' that needs to be directly involved in the current phase of the project.

Another type of communication is the status reporting to the project board and the internal project communication. In Prince2 this should be detailed in the communication plan that is part of the Project Initiation Plan (PID). Of course not all project boards are the same, but usually we are dealing with a company's leadership team, and they appreciate concise and consequent communication. This can range from a monthly progress report to a chat in the hallway, as long as the communication is structured, regular and complete. Don't be afraid to relay bad news! Decision makers usually appreciate you being candid and upfront about project problems rather than hearing about it too late. They may need to take decisions based on your reports that you don't know about, and with that in mind even bad news is better than no news! If you have bad news about the project because you bumped into a showstopper, make sure to get the project board involved; that's why they are there, to help you solve issues you have no control over.