Continue reading »]]> It’s very rare these days that you’ll see a project that isn’t adorned with a somewhat complex, several page, letters too small to read, lots of intersecting dependencies Gantt chart. Inevitably it may get trotted out every week at meetings where everyone’s asked if they’ve completed their scheduled tasks to which the answer will be an astonished – “is that what I was supposed to do?” Before the whole schedule has to get realigned to what’s “really” happening and once more the project manager disappears to undertake this not insignificant task – leaving the team to once again deviate from the schedule as it’s still being redrawn. Something about a vicious circle should probably apply here .

In this instance a project schedule instead of providing a framework for delivery of the project actually undermines the project by removing the project manager from the day to day delivery, keeping them focused on the drawing up a plan and not involved in what’s happening in the team, clearing road blocks and keeping the focus on what needs to be delivered now. I admit this view may be a little negative but, I think this should strike a chord with many of my readers. Although I’d have to say it’s more prevalent in industries with shorter delivery timescales such as IT or consulting projects instead of large scale construction or EPCM activities where the vastness of the undertaking merits this level of governance and bottom up planning!

So how does this bring us on to the death of the schedule you ask?

I guess it’s not really the death but a recalibration of the role of the schedule, but that doesn’t sound as good as a tag line. In essence the schedule still has a role to play it can be a good tool upfront to map out the project, visualise all the different tasks and dependencies and come up with an idea of timelines through bottom up estimation. That said it’s not an insignificant task to create and realign a project schedule so once this task has been completed upfront once and timelines are agreed with suitable milestones (say something significant every few weeks) then the schedule should become more of a reference tool only to be redrawn at significant stage boundaries.

Day to day management can be done by understanding what the next significant milestone is and gathering the team together to understand how this will be achieved in a collaborative environment. The focus here should be making sure that people understand exactly what they’re going to do next and feel some ownership over the tasks at hand as they’ve been involved – not by creating a non-personal list of bullet points as shown on a plan. In this instance the schedule becomes an input to the process – it’s the “what did we think we would do”, not the “what do we have to do” and “what will we actually do” which will likely have changed as new information comes to light throughout the project. It is this perception change in the project manager’s eyes of the schedule moving from the correct path to a previous best guess that will allow them to focus on what is actually happening and manage that as opposed to be relegated to the administrative role of updating project schedules.

Any comments I’d love to hear them?

Continue reading »]]> Sometimes it can be easy to get distracted by things that don’t need considering right now or by stretching the bounds of your scope and focusing your efforts elsewhere. Being in charge of a project one of the first things to strike you will be the limited amount of time available for you. Despite this it can be all too easy to be distracted by work that doesn’t need doing. This is after all the problem with the project managers exalted position of person who is expected to sort everything out for everyone!

One good idea to organise all of this work and make sure you’re focusing on the correct things is to mentally put a lot of these tasks, issues, etc into mental boxes. Once everything is neatly packed you can then decide how and when to deal with these things, if it all.

An example of this would be having a box (mental, virtual or figurative) called follow on work, into which you categorise all of the ideas, questions and work that may follow on from you current project. So whenever anyone has an idea outside of your current scope stick it in the box and deal with it when the time is right. This can be particularly useful for future work as you can then stick a task on your calendar towards the end of the project as a reminder and then pick everything up then. If anyone asks any questions about how things are being handled then you can confidently reply “these are our ideas and we’ll be picking them up on this date”.

Continue reading »]]> Just a quick snippet of (ironically) a concept that I’ve been playing with recently. What I’ve been wondering about how better to describe the decision making process which will be inherent throughout a lengthy project life cycle and ensure effective decision making in project teams?

So what’s the problem with the decision making process?

Well the particular decision process that I see as a major road block on a number of project teams is the one that requires specific individuals usually the PM with delegations in certain areas to specialists to make all the decisions.

At first that doesn’t seem to bad, however, it doesn’t allow for effective decision making in project teams, always moving in the best direction then this can really start to slow things up when people need to be waited on for a decision, particularly if an individual is absent for any length of time – days and sometimes weeks can be lost in this manner.

A second problem you may see is one of escalating the problem away from the field of expertise i.e. the person best situated to answer the problem is actually the one having the issue – they either just don’t know how to answer the question yet because of a lack of context or they don’t feel they can because of a lack of authority.

These are both areas that can be dealt with by introducing what I’ll term a “concept” into you project as a means of managing decision making. Concepts will be made of up two areas the what and the how, with the what stating the intent of this concept and the how telling you how it will be applied and how you will check that it’s being applied correctly.

The stated intents need not be long complex discussions on what you’re trying to achieve but rather a short well defined and understood list of what is cheifly important about the approach to project delivery, an example could be that the stated intent is to get something out quick and fast and then fix up once feedback is received, other intents may follow up projects that can be used as handy scope containers.

The how should also be kept nice and simple so that these ideas can live happily at the back of your teams mind without causing distraction. For example this concept is the most  important and we’ll quickly review decisions made in the daily stand up next day.

I’m hoping to flesh this out a little more over the next few weeks, but I would be interested to hear and respond to any comments on this area?

Pic from theswedish on sxc.hu

Continue reading »]]> Defining the correct approach to a project is one of the bedrocks of project management. Without a good clear understanding of how you’re going to achieve your aim there’s very little chance of your project running smoothly, never mind delivering the benefits you’re looking for. However there are a number of checks you can use to ensure that your approach is correct and one of the ones I would suggest is to check that your approach meets your intent.

The chances are that you came up with a project approach by going through this sort of process:

• Get everyone together in a room
• Make a statement of what you want to do

• Brainstorm ideas of what you can do
• Come up with an idea
• Elaborate on this;
• Change direction;
• Brainstorm some more
• Come up with the perfect approach!

There’s nothing wrong with this on face of it, however, I would issue the following word of caution. As you’re likely to go through this process you will very much be working in a divergent mindset and as such, it’s probably and perfectly natural that your focus has shifted from your initial intent.

As the PM in this situation your role should be to walk back through the approach consider what the outputs of the approach will actually be and then make sure it matches your initial intent. If it does great, if not then you may find it will with a few tweaks but at least you know that you can deliver what you set out to do.

Continue reading »]]> Getting a team of people all working in the same direction is one of the most important jobs of the project manager. One of the ways I like to do this is a plan on a page.

Consisting of a single page (I prefer A3), I would usually create a product or work package flow and then annotate this with the relevant points that need to be discussed.

The great thing about this approach is that you have a simple plan showing the flow of all your work on a page with suitable costs, times and issues flagged. Its easy to carry round and whip out in meetings or whenever anyone calls past your desk.

Use it to show people what you have in mind, show the impact of issues and show the whole picture on a single easy to read page.

Continue reading »]]> It’s great to get lots of people together in a room to collaborate on a document that needs writing, I personally feel it can really speed up the editing and approval process, see review cycles and the death of productivity, however this doesn’t mean we should through common sense out of the window.

The more people you bring into a room, the more opinions you will have gathered together on each subject and as such this will have an exponential impact on the amount of time spent off topic and exploring various “rabbit holes” in detail. If you’re in such a meeting whether you are chairing or not, you have a responsibility to stop this and keep things on track if only for your own sanity and time management.

Even if it’s your own particular fetish, don’t indulge! If something is off topic state it as such and suggest picking it up outside the meeting at a later date. At the end of the day everyone will thank you for keeping things on track.

Continue reading »]]> As a project manager it can be hard to get started sometimes, particularly if your new to the job or still unsure about how you’re going to structure a particular project or it’s deliverables. So what can you do to get those creative juices flowing and begin to write out the best project management controls / deliverables you’ve ever seen?

One of my favourite techniques is to lay out what I think might be the basic structure and then just start writing. The more I write the more ideas I have as I go along. As more ideas come to me I can revisit the structure and refine as I go.

What this generally means is that in the time it would have taken for me to um and ah and accomplish nothing I’ve actually produced a good framework of a document. Is it finished… No, but it’s a good start with a lot of my knowledge already typed up and easy to cut and paste around the page into whatever structure fits best!

I also find this helps weed out bad ideas, that might otherwise get through as once something is written down it becomes a little easier to argue with it and see if it is a good idea after all.

Continue reading »]]> I was recently asked to write a brief 100 words piece for a company newsletter, ideally funny and could I do it now. Well I came up with the following effort.

And so it began…

“Pete you like writing, write something for our Company Newsletter.”

“What would you like me to write?”

“Whatever people want to hear.”

Given such a clear brief (hell it’s better than a lot of client briefs!) I figured I was on to a winner here and kicked things off.

Strangely though thinking about what I wanted to hear wasn’t as simple as I first thought..? We all gladly ask for more communication when it’s not there, but pinpointing exactly what is the big void appears to be a bit harder.

Either way I’m out of words.

However as this is a different forum and I’m not kept to a 100 word maximum I’ll elaborate. It’s true that people will always view lack of communication as a major problem in any project, however when asked what people actually want to hear about it’s hard to pin point anything specific.

Now I believe that’s because people don’t want to hear anything specific they actually want to hear everything. We need to remember that it’s hard to know what the exact information someone needs is, as most people use any and all information they receive as a means of establishing context for their work, and indeed their life. Likewise exclusion from conversations or information is a very quick way to split a project team into silos and ruin productivity!

So I would always vouch for a principle of communicate everything you can and then make sure everything else is easy to find. People will always want to know more and it helps define their role so don’t be stingy with the communications and don’t set up a culture of secrecy unless you want things to fall to bits!

In practice this might include having an easily searchable project folder or site with all of your minutes, conducting discussions on message boards, including more people on emails or even putting key information up on a wall (one of my favourites).

Continue reading »]]> When you’re working on a project there will always be documents to write and because you write documents you will then get caught in review cycles.

The rough time split to get a document approved seems to be somethings in the region of 20% to write and 80% to refine and get approval (that’s probably being kind in some organisations!). So with that in mind anything you can do to make this quicker will help enormously.

Why the split? Well when you fire and forget emails to people to review you will inevitably get into a game of email ping pong with multiple versions of documents on multiple file stores / desktops / thumbdrives all out of sync wasting large amounts of time just pulling together all of the information and then trying to sort out the conflicting points!

The first suggestion I would make would be not to write documents but to collaborate on them. Maybe let someone write a very rough draft to get the bulk of the details into the template - which you should collaborate on to start with and then sit down together to review.

By completing the changes in a room ( / virtual room) with all the relevant people to hand all of the debates that would take days/weeks over email are streamlined into the process of the review. Better yet at the end of the review you already have the completed document ready to be formatted nicely and signed off.

Working over distance? No worries try some tools like Google docs and have live collaboration sessions down to the point of seeing exactly where someone else is working! In a more corporate environment – check out which version of SharePoint you may be using (lets face it most people are in some way by now) and if it’s 2010 use this as a means of sharing documents for “live” collaboration.

Continue reading »]]>

So right up front the take away point for this blog is that Project org charts are very important.

I’m sure everyone agrees with this, but experience seems to dictate that a project org chart is quickly sketched out with a minimal team and then forgotten. What inevitably happens is that more and more people become interested in your project, and you find yourself having to please all of these people who were never specified on the org chart.

But why does that matter isn’t this just stakeholder management?

In a way, yes. In another way no. Stakeholder management is not about ensuring that you personally make sure that anyone with a passing interest consumes your precious time to make them feel all warm and cuddly. It’s about ensuring that the correct process and responsibilities are in place to ensure everyone feels warm and cuddly. At the end of the day you only have a limited amount of time and if you find your self having to see to everyone personally this will run out and people will be forgotten and not be managed.

So how does an org chart help?

Glad you asked. The key is first of all to keep the org chart as a living document to describe everyone who your project interfaces with from the obvious people doing the work, to the somewhat more vague interested parties. Then you establish direct lines of management and reporting between the different areas of the project. As this is a living document you will naturally review this each time a new stakeholder et al comes along and put them into one of the appropriate camps in which they should be managed.

Depending on the camp in which they are placed will establish the relationship you will have with this new interested party. The list below gives some of the different holding buckets you could use and your relationship with these people.

• Project board: If someone’s in the project board then you need to look after them and report on a regular basis end of.
• User group: If you’re engaging someone from a user group then, you may be in luck here. If you have a senior user role then you may choose to let them handle the communication particularly if there’s a big group.
• Executive grouping: These are the guys who are paying for the project, however you usually wouldn’t have direct contact with these people, that’s why you have a project sponsor and it’s their job to manage these guys – make sure they’re aware of that.
• Suppliers: Generally you will manage most of the suppliers to the project, but if this is a large project and you’ve got a senior supplier / procurement or contracts role on board then add them into the correct bucket and let them deal with them.

Over the next couple of weeks I’m finalising some project tempates to be released under a creative commons license for comercial reuse and I’ll work up a usable org chart template to help you out with this and give a more visual representation of the org structure.