PMO Creation - Week 15

I'm the first to admit that my lack of bandwidth has stalled the efforts of my team. I am only able to steal myself away from my current project for a couple of hours every Wednesday morning to meet with my team and then show up at the Steering Committee meeting every Friday morning. That means Mike and Sarah and left with all the heavy lifting.

As a result, the consolidated project plan they put together for this week's meeting, that looked pretty sparse on Wednesday, did not meet our CEO's satisfaction by Friday. Frankly we all looked pretty bad. I promised we would have a better one in place by next week and that I would meet with one of our teams to show what we wanted to accomplish.

That meeting was like pulling teeth. The team members were confused about what we were asking. Even though I had put the leader through my Cadence training a few years back, she couldn't seem to understand that by giving me hours of effort she still had to have a conversation with me to determine the durations. She was convinced that this was simply dependent on priority and didn't get that other tasks within her high priority projects and time spent on ongoing operations could affect these durations.

Another leader in this group expressed the opinion that all Project Management is useless. One of the lower level guys said that they just do a bunch of work whenever and pay no attention to priorities. The other two lower level women just smiled and nodded. It is becoming clearer and clearer to me that we are doing some things backwards. We really needed to train the employees in the methodology before trying to plan these projects.

Also we should have had a formal announcement from the CEO expressing his confidence in the PMO and the process we are following and get his authority to ask these questions. Mike has been good about bugging me to ask for this and we received a draft from the marketing group of an announcement. Here it is slightly redacted:

All,

As you may know, Bruce Fieggen, QPharma’s longtime VP of Project Management, has agreed to take the helm of QPharma’s Project Management Office in addition to his client-facing duties. 

The QPharma Project Management Office, or PMO, is responsible for prioritizing, scheduling, resourcing, and managing the many internal projects necessary for the ongoing operation of our Commercial Services division — most notably, the development of Python™ and our other Information Technology systems.  It is crucial to the PMO’s success that all colleagues cooperate fully with PMO deadlines, resource requirements, requests for information, etc. — please accept my thanks, in advance, for your active participation in this process.

Over the past several weeks, a Project Management Steering Committee has been formed, and we have been meeting regularly and going about the arduous process of identifying and prioritizing the dozens of projects that demand QPharma’s attention.  In the coming weeks and months, please expect to hear from Bruce, his two Project Managers (Sarah Gerardo and Michael Gerace), and other members of the Steering Committee with various requests related to your role in helping this effort run smoothly.

I look forward to keeping you informed as our important work progresses.  Once again, thank you.

Kind regards,

CEO

PMO Creation - Week 14

No steering committee meeting this week so my team could focus on getting the Master Gantt chart together. Let's hope they pull it off to the CEO's satisfaction. I am still too busy on my current project and putting together proposals for two new projects to be much help. I'll see what they come up with on Wednesday and give them some advice.

Dear PM Advisor. May 19, 2014

Dear PM Advisor,

I work at a consulting firm that is developing a lot of small IT projects at one time. I've been trying to get the steering committee interested in using the Software Development LifeCycle (SDLC) that I used at previous companies but my proposal got squashed immediately. Enclosed is a project plan template that is very similar to what we used at UPS and Medco which made IT DEV project management run very smooth (not to mention both were multi-billion dollar corporations). 

My point is, if it worked successfully there, I don’t see why we cannot implement this strategy/methodology here. I understand that we have a SDLC methodology here (scaled down – that NO ONE uses) but adding this release calendar to just the IT dev projects would add tremendous value to both the PMO and IT. 

Personally, I think IT would love this methodology in place (I know I do). Let me know your thoughts.

Tied up in Morristown, NJ

Dear Tied up.

It all seems quite reasonable. Why not use these tasks when you plan your projects? You can guide the team members to come up with the wording you want. Sometimes they’ll balk and you use their wording but it means the same to you. That’s what I do when I plan projects. Here’s the conversation:

“So the first thing we need to do is plan this project, right? How about we say Concept proposal? Have you done that already? You have? Good. Then we have to Identify vision and scope. That’s what we’re doing now. Do you know the deliverables? OK, from there we create the project plan.”

And so on until they are using the deliverables and tasks you are familiar with.

I always do that with my projects so that I know what is happening on the project I plan and execute. Often people will add tasks that I don’t have in my template which are specific to that project and the way they do things. I’ll compromise there. 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

PMO Creation - Week 13

During my weekly PMO meeting I apologized to my team for allowing them to be criticized by the CEO for not being prepared. I promised I would stick up for them in the steering committee meeting.

During the first part of the steering committee meeting I spent the first few minutes insisting that the chain of command be followed and that nobody criticizes my people but me. It was tense but my CEO trusts me. I reminded him of what I told him during my interview when he asked: "What am I going to find out about you two weeks after I hire you that I wish I knew now?" I told him: "I'm blunt." And I've proved that to be right many times since.

After the dust had settled we got back to the agenda with one added item. Our big software program: Rock Python, had many elements that people wanted prioritized. On opening this file up, we saw that some of the projects were actually sub-projects of others. But the people were not showing how many resources were needed on a weekly basis because they didn't understand how the system worked. I was very frustrated.

Once again we looked for completed projects and once again, none quite got there. I reminded the steering committee that these projects were supposed to last 2 - 4 weeks and many should have completed by now. We all agreed that this system was really highlighting this deficiency.

The CEO asked for something out of the ordinary. Could he please pull the non-IT projects out of the list and make them their own separate list. I told him this was OK as long as they did not require resources from the other projects. He agreed and pulled about 12 projects out of the main list. We re-prioritized these and moved to resourcing.

The rest of the steering committee was getting frustrated at trying to figure out how many hours people would need to spend over how much time. (Duration vs. Level of Effort) So the CEO asked for another new thing. Could we place all the IT projects on one Gantt chart and track level of effort there? I was dubious but, since the Excel sheet wasn't working, I decided to give it a try.

He asked how you do this. I showed him one of my projects' Gantt charts showing how I break out Work from Duration and allow MS-Project to calculate % of resources required per task. I showed how this allowed one to see the resource graph and highlight where resources were scarce.

He was excited and asked that my team create this master Gantt chart. I asked for two weeks for them to perform this work. We argued back and forth but I got my team two weeks. Let's hope they pull it off. The CEO promised to do the same job by himself for teh non-IT projects over the weekend.

Dear PM Advisor. Mar 31, 2014

Dear PM Advisor,

I'm very good at breaking down a big project into smaller, manageable chunks. But my main hindrance is the procrastination. I put off the work for a later time. Any tips to overcome this issue?

Regards,

The late Robert from China

Dear Robert,

It has been my experience that people react to urgent activities before they react to important activities. Perhaps it is built into our DNA. We were bred to run from the lion before planting wheat for the winter food supply.

One finding we have discovered in Project Management is that activities scheduled for three weeks or more are more likely to come in late. When faced with a deadline that far into the future, people will work on activities with a nearer deadline rather than the further one, regardless of the effect on the critical path.

How do we deal with this? Simply by breaking down these activities into sub tasks and sub tasks into work packages until the lowest level of detail results in a task that is scheduled to take no longer than three weeks.

In most cases this is quite easy but there are two exceptions which can be dealt with in different ways.

1. The activity that must take 3 months like aging studies. Simply put the product on the shelf or in the incubator and set an alarm on your calendar to take them out and examine or test them on that date. Those tasks won't come in late because you are typically waiting until the second you can remove them and test to see if they still work..
2. The vendor with a six month lead time. Try to ask them to break down their activities to the sub task level so that you can follow up closely on their progress. But they may not do it. Therefore, you need to manage this activity closer than other activities on the project. Call them often to ask about their progress. Visit them. Be a pain in their side so that the only way they can get rid of you is by finishing the activity. 

This should help you with late activities throughout the team. But you admitted that you are the procrastinator so how can I help you with your problem?

Once you have broken your activities into smaller than three week units, work on those that are on the critical path. Be honest about the %complete these activities are on a daily basis. For example, if the activity is scheduled to last two weeks, every day you should be 10% further along. Set yourself a goal to exceed that percentage and give yourself a little reward if you achieve that goal. If you get behind on one day, you don't get the reward unless you completely catch up the following day. 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Mar 24, 2014

Dear PM Advisor,

I am a team member on a project and my Project Manager is strict about me meeting my activity deadlines. So I add a buffer when she asks me how long an activity takes. Recently I admitted I was doing this and she got real mad at me. She gets a buffer; why shouldn't I? 

War On Buffer in Cambridge, MA

Dear War On,

Buffers are a very tricky thing. Let's take your example to the extreme to see why not everyone should get a buffer and then show you why the way your PM is acting is correct.

Say the project is composed of a bunch of activities and all the team members add 25% as a buffer to the schedule and cost of each of these activities. Then their functional managers add another 25% to ensure their departments don't look bad. Then the PM adds 25% to make sure she can hit the baselines. The Steering Committee adds 25% before they decide if they want to pursue it. What does this do to a project that should have taken a year and cost $1,000,000?

12 mo x 1.25 = 15 mo. $1,000,000 x 1.25 = $1,250,000 (Team Member buffer)
15 mo x 1.25 = 19 mo. $1,687,500 x 1.25 = $1,562,500 (Functional Manager buffer)
19 mo x 1.25 = 23 mo. $1,562,500 x 1.25 = $1,953,125 (Project Manager buffer)
23 mo x 1.25 = 29 mo. $1,953,125 x 1.25 = $2,441,406 (Steering Committee buffer)

So our project more than doubled in size by adding all these buffers. Sounds good to you, right? But the steering committee may look at this and decide the project is not worth doing. And your leaner competitor will beat you to the market. So you won't be doing projects much longer here either way.

Buffer given out it is rarely given back. If you realize that the three day activity has been buffered to seven days, you probably won't start it right away and you won't feel the pressure to finish it in three days. So you'll start it on day three and finish it on day seven and feel proud of your accomplishment.

Here is the right way to add buffer to a project:

1. Each Team Member estimates the activity duration and cost given the most likely scenario while feeling pressure. They don't add buffer.
2. The Functional Managers review the TM's estimates and make adjustments if they think the TM made errors. They also don't add buffer. 
3. The Project Manager adds up all the costs and durations and determines the overall budget and schedule for the project. She also looks at the risks associated with this project and suggests a buffer based on all the known unknowns. She adds that to the request to the Steering Committee. 
4. The Steering Committee adds a buffer to account for all the things that go wrong on projects that we don't identify during the planning session. These unknown unknowns are taken care of using the Management Reserve, usually around 20%.

Let's look at what this does to our project:

12 mo x 1.00 = 12 mo. $1,000,000 x 1.00 = $1,000,000 (Team Member NO buffer)
12 mo x 1.00 = 12 mo. $1,000,000 x 1.00 = $1,000,000 (Functional Manager NO buffer)
12 mo x 1.10 = 13 mo. $1,000,000 x 1.10 = $1,100,000 (Project Manager Risk buffer)
13 mo x 1.20 = 16 mo. $1,100,000 x 1.20 = $1,320,000 (Steering Committee Management Reserve)

Now our project has an appropriate buffer but is still doable. The Team Members will feel pressure but they can accomplish their work.

But pay close attention to how we use this buffer. When you estimated three days on an activity, you need to do it in that time. Even though the overall project's schedule has been increased by 32%, you don't get to use that on every activity. That buffer belongs to the PM and she gets to distribute it when needed. She should be stingy with it. Remember it was placed there for Known Risks and Unknown Risks.

So you get three days for your activity. If you run into a problem you hadn't expected or hit a risk you had identified and you need another day, the PM should provide this from her four-month buffer. If you finish the next activity a day early, give that day back to her so she can add it back to the buffer. She will need every day she can get for that big problem that hits every project.

Wow! Long answer for a simple question but that was an important question that a lot of people get wrong.

Good luck,

PM Advisor.

Send your questions to Bruce@RoundTablePM.com

PMO Creation - Week 3

Now that we have a mission, it's time to determine how to put this into practice. I did a bit of research and found an excellent site that advises people on how to set up a PMO. Here it is: www.practicalpmo.com.
Simon Wilkinson offers a free 7 steps guide and plugs his book. I may yet buy that book.

With his free guide in hand, I sat down with my team and developed a Gantt chart for the work we see ahead of us. Using good PM practices, I asked them to volunteer for activities and give me their estimates for duration. We are using this to complete our activities and check on our progress as we proceed. Here's a link to the Gantt chart we came up with:

Once again I distributed this chart to those who will be affected immediately by this work. I am not distributing it to the PMs outside the PMO until we have our processes in place. We want to be perceived as an asset to their efforts, not something else that starts with the same three letters.

Dear PM Advisor. Mar 3, 2014

Dear PM Advisor,

When I'm generating a Work Breakdown Structure, the pattern for the completion of documents is always the same. Draft, Review, Edit, Review, Edit, Approve. Can't I just list all the documents as the one deliverable, place all the activities underneath it and I'm done with that section of the WBS? It seems a lot easier but I'm afraid I'll pay for it later?

Short-cut in Cambridge.

Dear Short-cut,

As the CarTalk denizens of your fair city are quick to point out: "It's the stingy man who pays the most!" As you suspect, there will be a payment for taking this short-cut. But it may not be as bad as you suspect.

Just remember what your next steps are after filling out the WBS. The activities need to be placed on the Responsibility Matrix and people need to volunteer for who will take responsibility for them. If they are all the same people on every document, you could be in luck. Most likely this is not the case.

Then the activities need to be placed in the schedule. If you're using MS-Project at this point, a simple cut and paste will help but you'll need to add the word describing each actual document. I'm a big proponent of activities standing alone. You shouldn't have activities named: Review. You'll have to scroll up each time to see exactly what the person is reviewing.

Next you have to add the durations and predecessors and they will vary by document.

My preference is to have each activity broken out within the WBS. You can use this as an opportunity to involve the people who have little to add to the WBS by asking them to repeat the activities you wrote under one document for all the other documents. Great opportunity for some team building.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Jan 13, 2014

Dear PM Advisor,

I am working at a client to help them implement their new owner's policies and procedures since they were acquired.  I am an individual contributor and not the PM.  They are following the new owner's PM philosophy of Critical Chain Project Management.  They have purchased a tool for MS Project from ProChain.  Have you heard of this approach?  I see some issues with it and am curious to see how this will play out.  But overall I really don't see any advantage to it over our practices.  Or am I missing something?  Here is a link to the demo:

http://www.youtube.com/watch?v=7Xf-waj23P8

Regards,

Unchained in Wayne, NJ

Dear Unchained,

I've always loved the critical chain technique but have been unsuccessful implementing it since it requires serious senior management support. Looking at the video, I'd say your client has an excellent opportunity for gaining the value of this wonderful technique.

First of all, I LOVE the video! In 15 minutes they completely explain the technique, the software and the management support required. If you are unclear how the system works, watch it again.

If you need me to explain it to you, I'll try to do so in my words:

1. All tasks have an uncertainty, so those committing to task deadlines include that buffer in that duration.
2. Buffer taken is rarely given back so tasks rarely finish ahead of schedule.
3. Critical chain project management consolidates all those individual task buffers and puts it under the control of the PM who gives it out and takes it back from task owners as needed.
4. People work to priorities rather than deadlines. 
5. All projects must be prioritized for this system to work.
6. People must be allowed to finish tasks late if priorities demand it.
7. Project management focuses on buffer management.

The software ProChain sells allows management to focus on buffer management within prioritized projects.

My advice is to embrace this technique and learn all you can while you have this rare opportunity. Then let me know how you liked it. 

Good luck.

PM Advisor. 

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Dec 16, 2013

Dear PM Advisor,

When I schedule my activities in MS-Project, should I use best-case or worst case? Should I let people add a buffer to their activity durations? 

Protecting myself in New Jersey

Dear Protecting,

• Never use best case since projects are bound to have problems and you will miss the deadlines you promised your management. 
• Never use worst case since your projects will always show due dates way beyond where management knows they should be.
• Never allow people to add buffers to their activities since that will also result in completion dates too far in the future. 

So what does that leave you? Most-likely case with the buffer added in at the management level, not the team level. Let me explain. First we'll talk about the number of tasks you add to your Work Breakdown Structure.

Say one of your activities is the coding of some software or the creation of some document. Best case would have you code the software and sell it. That never happens. You code, test, fix, test, then approve. Sometimes you go through three or four rounds of test and fix before you are happy with it. Same with documents. So your Work Breakdown Structure  needs to include all these steps:

• Draft, review, edit, review, edit, approve.
• Code, test, repair, test, repair, test, repair, test, approve

Whatever is common practice at your company should be planned for the current project.

Now we need to talk about buffers. When someone estimates the duration of their activities, they should give you the most likely case without a buffer. You add these all up according to the network to determine the overall project timeline. You present this to management. Since you have added all the 'known unknowns' as represented by the redo activites, you are done. At this point, management adds a buffer to take into account all the 'unknown unknowns.' They may choose to add 10 - 20% to the overall time required by the project.

You, the Project Manager, own this buffer. If someone requires an extra day to complete a task, you take it out of your buffer. If someone finishes an activity two days ahead of shedule, notify the next person down the line of the change in schedule and add these days to your buffer. And when the bad thing happens to your project and you need those extra two weeks, you have them there in the buffer.

Another time I'll address the subject of maintaining control of the buffer.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Dec 9, 2013

Dear PM Advisor,

When I schedule activities in my Gantt chart, my boss likes to see all the deliverables as milestones. I'm used to showing them as summary tasks above all the activities. What do you recommend?

Stony in Morristown, NJ

Dear Stony,

Who writes your review at the end of the year? Who is responsible for any bonuses, promotions and career growth? Give that person what they want.

People have varying levels of comfort with MS-Project. Some like to see how long each deliverable takes, seeing it from the beginning of the first activity to the end of the last one. When you roll up a Gannt chart with the default settings, you will see this.

Others look at this and just see a bunch of bars and get confused. They just want pinpoints showing when each deliverable is completed. A nice diamond at the end of each deliverable works for them. When you roll up this type of Gantt chart, you can see all the diamonds.

Still another group wants to see both.

A fourth group, I count myself in this group, want to see the full summary task type deliverable bar with milestones indicated where they are important: Design Review Complete, Go-Live, things like that.

The bottom line is this: 90% of a Project Manager's job is communication. So communicate the way your stakeholders want to be communicated to. Especially if that stakeholder is your boss.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Nov 4, 2013

Dear PM Advisor,

I was taking a PMP Prep course recently and a question used the term: "Max Crash Days." This was on a question about decreasing the critical path of a project using crashing and fast tracking. How does one determine Max Crash Days? Shouldn't you be able to crash further?

Crasher in Washington D.C.

Dear Crasher,

Crashing is the process of adding resources to an activity in the hopes of decreasing the duration. This works to a certain extent but not infinitely. The classic example is asking nine women to reach full term pregnancy in one month. Real examples are the addition of a person and another lathe to a metal shaping activity which can halve the duration but eventually you run out of people, or lathes or shifts and you reach that max crash state.

Other tasks are delayed by adding resources. Creation of a document can be an example of this where two minds add inefficency to the activity.

For the purpose of the PMP test, they need to tell you the max crash since they usually don't specify the actual activity and you just look at Activity B and say to yourself: "Let's double the resources and halve the time."

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Oct 28, 2013

Dear PM Advisor,

My company has been unstable lately and my team members are leaving for more secure opportunities. What do I do with the schedule now that fewer and fewer people are working on the same amount of activities?

Sinking Ship in Washington, D.C

Dear Sinking Ship,

I'm hoping you resource-loaded your Project Schedule to show the effort required for each activity. That way you can show how many hours of effort are required. Remember, the hours don't leave with the vanishing team member.

You can then reassign those hours to the remaining team members and level the work to reflect that they only work 8 - 10 hours a day.

This inevitably results in lengthening the duration of the activities and the end date of your project. If anyone argues about your lengthening schedule, show them the facts that indicate why this was necessary.

If you weren't proactive enough to load your project correctly before, sit down with your existing team and plan out the number of hours of effort on the remaining activities and schedule them according to the availability of these resources. Now you just have to tell management: "I had thirteen team members, I'm down to ten, here's the effect on my schedule. If I lose any more, it will increase in duration, if you give me additional resources, I can reduce the schedule. The two go hand in hand."

Good luck,

PM Advisor.

Send your questions to Bruce@RoundTable PM.com

Dear PM Advisor. Aug 26, 2013

Dear PM Advisor,

How do you handle overly optimistic folks - those who commit to deliver too much in an impossibly short time?

How do you handle them when senior management loves what they are saying?

If I object - I'm seen as 'not having a positive attitude.'

 

Just Another Engineer

Dear Engineer,

I love those optimistic folks. I'm one myself. But I imagine your concern is that they commit themselves to unrealistic timelines which ends up delaying the overall project. So let's focus on that aspect of their personalities.

As a Project Manager, during the planning phase, you need to have Team Members commit to hours of effort and duration for the tasks for which they take responsibility. They should make those commitments in front of their peers so that they are more likely to live up to those commitments. If you don't believe their commitments are doable, now is not the time to say so. 

But when the project is fully planned, you need to look at their time committed to this project based on all these individual commitments and compare that to the time they are actually available on the project. And when they are over-committed, you need to increase the durations or slip tasks to ensure they can work within their resource constraints. But that did not address any low estimates they may have made. Once again, now is not the time to say anything. 

Wait until the project gets going. Then manage their time on task more carefully than you would manage those whose time seemed more reasonable during planning. If they live up to their commitments, you are golden. More likely, they will not be able to meet those aggressive timelines. Gather your facts. 

When you have enough data to convince them, show them the facts in a Gantt chart with Baseline Start and Finish Dates. Your conversation should go along these lines. "On the first three tasks you actually completed them in twice the duration you planned. Is this a systemic problem or a one-time problem? If this is systemic, what do you say we double the durations of all your subsequent tasks and put it down to being overly optimistic? If it's a one-time problem, what was the exact nature of the delay and let's figure out how to prevent that happening again in the future."

That should solve the immediate problem and force them to make better estimates on future projects. 

As to the management who loves the optimist's estimates, make sure they are copied on the status report that shows that we are doubling the optimist's estimates in the future and why. 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Aug 19, 2013

Dear PM Advisor,

Do you need dedicated resources to be successful on a project?

Lonely in Maryland. 

Dear Lonely,

To quote Groucho Marx: I doesn't huit!

But back in the real world, you almost never get dedicated resources so you would almost never succeed if the above statement were true. (By dedicated, I assume you mean people fully committed 100% of their time to your project.)

For one thing, even if your resources were 100% committed to your project, they may still have two tasks taking up all their time at the same time so this doesn't guarantee success. More likely, though, is that they are working many tasks some percentage of their time over the course of your project. Your job is to ensure that they are not a bottleneck. How do you do this?

When you plan your project, determine how much time they are dedicating to each task, not just the duration of the task. Plug this number into the work column of your Gantt chart. MS-Project will calculate the %time required by your resource over that period. Do this on all tasks and it will nicely add it up for you on a daily basis.

Now you have to look over the View Resource Graph to see where people exceed the % allocated to your project and do something about it. You can set this allocation % in the View Resource Sheet view. Whenever the resource exceeds the allocated %, the bar graph will show red. You need to deal with that.

Before you get too excited, make sure your timescale is correct. Notice in the above graph, it looks like I'm 100% required for a whole week in July while I'm available only 50%. But when I zero in to this week, you see it is only one day that I'm overloaded. Project will show the worst case for each time period, not average.

If you zoomed out I would appear to be 100% loaded for the entire month or year. So look instead for the details.

Next step is to do something about it. You could increase the duration of all activities on that day so that the resource is back within their availability. But be more specific. Look at the tasks using up that time and only increase the duration of tasks not on the critical path. Or delay those tasks to when that resource has availability. Look at the View Resource Usage view to see what is going on:

Here you see it is me drafting the project plan in one day. An activity that is off the critical path. I can do it in two days, or do it in one and spend all the next day on my other project.

But do this manually. Project can do it for you automatically but it cares nothing for the nuances of your project. It will simply increase all durations until everyone is properly resourced with the result being that your one year project will now take ten years. Seriously!

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Sixty-third excerpt from 'Twelve Towers'

          That night, Gwilym had an epiphany for his human resource problem. The next day, once the crew was working hard, he went back into the village and purchased some cheap, colored cloth and a pair of spring scissors.

          He set about cutting this cloth into many small squares, each about an inch square. Then he took some paper and lined it like they had yesterday with axes showing dates on the x axis and number of people on the y axis. Each week on the x-axis and each half person on the y axis was one inch long. He made one for each skill. Then he called Fred in.

          Gwilym explained his idea to Fred. “Each one of these colored squares indicates half a person of a particular skill working for a week.” He placed two on top of each other. “This represents a whole person working for a week. We place this on the chart and we can see what we need given the current schedule. Then, when we change the schedule, we move the pieces of cloth around to make sure we don’t overload our people.”

          Fred’s eyes grew wide as he understood, and the two men worked together, placing squares, adjusting the schedule, moving squares, sometimes cutting them further down to indicate a quarter person on even vertically to indicate someone working for a day or two rather than for a week. Within a few hours they were done. They had reached a point where the schedule could be met without stretching resources anywhere. There were a few occasions when they would have to bring on some extra laborers and other occasions when work off the critical path would have to sit until there was a lull in other activities. But their schedule was doable now and the men would have plenty of warning when they could take time off the project and work their fields.

          During dinner they stitched the cloth pieces to the paper. Then Fred redid the calendar and placed it on the wall where every member of the team could see it. As the crew left the job-site at the end of the day, Gwilym showed it to them. Each crew member followed their plan on the calendar and took note of the days they would be expected to leave the project.

          “How good are you at predicting de future, Gwilym?” asked Tollemache.

          “The schedule should be pretty accurate for the next few weeks. Then things will happen that will change the predictions but I will keep this calendar up-to-date. Keep checking back to see how things will change. If you have plans that cannot be changed due to your farm, it becomes my problem.”

          The men nodded and walked off home. “What do tha call this tool, Gwilym?”

“Resource planning. No. There will be other plans we need for resources like stone and wood. How about Human Resource Plan? Yes. I like that. Are you putting it in your book?”

          “Aye, Gwilym. The song was getting too hard to rhyme. Would you like to see it?”

Gwilym nodded and Fred showed him the book. He had a page in the front that titled all the tools and each page that followed described the tools in detail. So far, the title page had the following entries:

          Charter

          Stakeholder List

          Project Management Plan

          Requirements

          Scope

          Work Breakdown Structure

          Activities

          Activity Sequence

          Activity Resource

          Activity Duration

          Schedule

          Activity Costs

          Budget

          Human Resource Plan

          Gwilym smiled and shook his head. “Fourteen elements to planning a project! And I still think we’re missing some things. What else can you think of, Fred?”

          “It would be nice to plan th’bad things that seem to happen on every project, th’things that always seem to go wrong.”

          “I’m not sure if that’s possible, but it bears thinking about. What about the stakeholders? We identified them early and came up with a list of them. What are we going to do about them? How are we going to tell them about the project?”

          “I like these matrixes. Why don’t I create one for this, too.”

          Fred listed the stakeholders of this project on the x axis and the different communications on the y axis. Project plan, Calendar, Schedule, Budget. “What else, Gwilym?”

          “We should have regular meetings with the team to see how things are going. Call them Status Meetings. We should put out Progress Reports for people like Sir Kay to see. He’ll also want reporting on budget.”

	Sir Kay	King Arthur	Euros	Mostyn.	Nantlais	Merlin	Tollemache	Project Team	Quarry	Sawmill	Fred’s Project Notebook
Project Plan	I	I					I	I	I	I	W
Charter	I	I					I	I			W
Status Reports							W	W	W	W	W
Status Meeting Minutes							W	W	W	W	W
Budget	Q	Q	Q								Q
Calendar							D	D	W	W	M
Requirements	I	I		I	I	I	I	I	I	I	I
Progress Reports	Q						W	W			W
Issue/Problem Log	Q						W	W			W
Contracts	I		I				I		I	I	I

           

          Fred and Gwilym decided how often people would get information and placed notes at the intersection in the matrix. I for as issued, W for weekly, M for monthly, Q for Quarterly.

          Fred added the Communications Plan to his Project Management Plan book and Gwilym followed the plan for all their project information.

To read the entire first draft in one shot, click here: