March 23 – Testing Done Right

My team recently had a small part to play in a huge implementation. There were something like 23 interfaces with other departments and outside organizations, thousands of modules and the actual implementation took nearly 48 hours. To give you an idea of the size, our small part included the removal of nearly 200 jobs and over a million lines of code. Even with all the activity, all systems were up and running on Monday without a problem.

Several team members came from a competitor that had recently done a similar system revamp. They brought with them horror stories of how things went horribly wrong. Upon implementation, they spent 3 months nursing the system back to health resulting in cash flow problems with major impacts on the business.

So why were we successful? The simple reason is testing. All projects go through testing phases, so what was special about the testing for this project?

Quality first. Early on the organization recognized the fact that quality counts. If you don’t put quality first you end up paying for it somewhere, especially on a major endeavor like this one. Verification had to be done or it wouldn’t go forward. This was the first project I have been on where the testing time was not chopped in order to cram the system in on time.

Truly Coordinated Testing. A separate project manager was put in charge of testing. Her job was to orchestrate several all encompassing System Tests with all involved parties. Tracking the database extracts and necessary datasets from capture through processing was a major undertaking.

Near Shore / Off Shore model. With the team spread from Halifax, Nova Scotia and Noida, India testing could be performed around the clock. Data was processed through the systems and made available to the online application for business review and approval.

Automated Test System. An in house scheduling tool referred to as a “Test Harness” allowed the jobs to be laid out ahead of time with dependencies and input files. This allowed execution without the usual human intervention of submitting jobs.

Testing in the DR Environment. More and more companies have solid Disaster Recovery (DR) systems on which they can revive their systems in the event of a major problem. Usually these systems are only used for recovery tests and live emergencies. The operations group reconfigured the system for use by the team to perform 2 full dress rehearsals of the event. This allowed us to bring up the full current environment and perform the conversion just as if it were production.

Not stopping at implementation. The implementation required the system to be down through all of the normal weekend processing. A limited Saturday “catch up” cycle was created and run on Sunday before a modified Sunday processing began. As part of the DR environment tests these two batch processes were executed. The results of those tests allowed adjustments to be made for smoother execution on go live weekend.

No fear of saying “No Go!” Technically we signed up for 1 dress rehearsal. When the first one didn’t go as smoothly as was hoped, the business decided to push the implementation date back a month and have another run at it. Other companies may have degraded the IT department and forced them to implement on the original date.

Bottom line? The success of this project shows that testing works if you actually get to do it right.

March 26 – Budget Management Checkbook Style

This article was originally published at http://projectmanagementlearningcenter.com.

I have really messed up my checkbook. It started around Christmas time. When I tried to balance it in January I failed miserably. Since I can balance the budget for a multi-million dollar project I should be able to handle a checkbook that borders on empty every month. Even with a new Quicken file in February, I was still unsuccessful this weekend in determining what I have left. If I don’t get it right I won’t know how much I have available and will likely end up bouncing checks.

What surprises me is the number of project managers that don’t put the effort in to balance their project budget. Every time someone expends effort on your project it is like a check being posted against your account. If you don’t capture and track those transactions you will eat through your budget faster than high school kids through your refrigerator.

Here are 4 basic concepts of budget management to put into practice.

Know your budget. I started a multi-person, multi-email discussion recently about the budget on a project. I knew what the overall cost of the project was but it included a Fixed Price Premium (FPP). An FPP is added to the cost of the project by the consulting company to offset the risk involved with a fixed price project. Since it is basically an insurance policy, it is outside of the budget for the project. I had to find out what that amount was in order to develop the baseline for the cost.

Create your schedule to the budget. Assign resources to the tasks with costs per hour for those resources. If you are responsible for the hardware, software, facilities, etc., include them in your schedule. This gives you a projected cost for the effort. If, after realistically created the tasks and applied the resources, you are over budget there are a couple of steps you can take.
1. Review the strategy and see if there are any shortcuts that can be applied.
2. Use cheaper resources to accomplish the same tasks.
3. Revisit the scope to see if anything can be removed.
4. Ask for more money for your budget. It may be a little early in the project for this one, though.

If your totals show you under budget, recheck to make sure you didn’t forget anything and then place the remaining amount in your schedule as a contingent reserve (hidden fund for future unknown problems).

Track your expenses. Each week your resources’ timesheets deduct money from the project. If that time is not applied against your schedule it is like using your debit card and throwing the receipts away. Eventually your bank is going to send you nasty letters telling you there is no money left and, to prove their point, deducting $20 more from you.

Record time spent against the tasks worked. This is simpler if you have time tracking software like MS Project Server, Clarity or Primavera but it can be done manually. You can collect paper or electronic timesheets showing actual effort against a task list and enter it into the schedule.

As you do this you will see areas where you are expending more than was planned and take corrective actions.

Balance the books. The finance group should issue statements from time to time showing the charges to the project. Take the time to match invoices and timesheet totals back to your schedule. This is where you will find people that are charging to your project that you didn’t know about. It also helps you confirm your budget still exists.

A multi-millions dollar project I was managing had saved nearly $1.5 million by altering their hardware needs. This savings was part of the contingent reserve on my schedule. When I balanced back against the numbers from finance the budget was off by $1.5 million. It was discovered that the in final budget submitted the savings were removed and given to other projects. It was a shock to go from extremely under budget to barely on target, but it was better to find out midway through than when the checks started bouncing.

Tracking your budget is about as much fun as balancing your checkbook, but not doing either one will land you in trouble.

March 22 – Understanding Authority Levels

The purpose of authority is to accomplish the goals of a project or organization. But authority is a slippery thing. This is especially true for a consultant. On one assignment you are the program manager over several projects and the next you might be reporting to one of your former project managers. Keeping that perspective helps you refrain from abusing your power.

Here are a couple of other things I have learned about authority.

No Respect. Project Managers generally have no direct authority, especially in a matrix environment. The only real authority you have is either given to you or earned.

Take as much as you want. Many people are willing to give up authority if you are willing to do the work that goes with it. Obviously there are limits, especially in organizations based on authority and when dealing with power hungry individuals, but in general you will find this true. The key is to pick and choose the responsibilities that will help your project be successfully. One overlooked but powerful position is meeting ownership. If you can control the agenda and minutes for a meeting you hold a strategic place. It may sound boring but deciding what is discussed and being able to steer the conversation where you want is powerful.

Positional Authority. This is probably the weakest form of authority, but is usually the most abused. Its weakness comes from the fact that it isn’t always deserved, doesn’t necessarily come with respect and can be taken away as quickly as given. That doesn’t mean it isn’t useful. As a project manager, your Charter or other defining documents give you the authority to run the project. Use it with respect for individuals and it can help you move obstacles. Another form of this authority is base on your upper management. Essentially this is name dropping. If you start your email by saying the VP of Finance asked you to follow up on something it will probably get a faster response than just asking nicely.

Referent Authority. This includes your ability to influence others through your charisma, personality and charm. If you are a great person to be around people will want to be on your projects. Your team will want you to succeed and will work harder to make it happen.

Coercive and Reward Authorities. The use of punishment and positive reinforcement are two types of authority that can be effective. The possibility of a better project, more pay or a new job title can encourage people to put in extra effort. Demoting or taking privileges away can correct help bad behavior or encourage people to seek employment elsewhere. The problem is that these only work until you’ve ticked your team off or you no longer have anything to offer.

Expert Authority. If you can earn the respect of your team and management you have the highest level of authority anyone can achieve. No, I’m not talking about the respect that Al Capone had by roughing people up. Respect is earned by successfully managing projects and treating people right. Real respect makes people want to work for you because of your abilities and it makes your team want to you to be successful.

Whatever authority you are wielding, remember to use it for good and not evil.

March 20 – Random Lessons Learned

Learning from your mistakes is a good but to learn from someone else’s mistakes saves a lot of time. The trick is to find someone willing to admit their mistakes. Fortunately I am secure enough in my stupidity to share a couple of mine.

Don’t be a bonehead. I remember trying to walk through an audit with a project manager that just didn’t seem to be getting the concept of project tracking. Rather than patiently working it through with him I blurted out, “Are you sure you want to be a project manager? We could probably work you back in to a technical field.” That effectively ended the conversation.

Avoid poking dragons. Within our consulting company everyone from newbie to upper management is expected to create a status report. As a member of the Project Office I was tracking and reporting on the number of individuals who where not producing them. During a meeting with upper management someone asked why I thought people weren’t doing it. In response I verbally picked up a stick and poked the management dragons by saying, “it could be because management isn’t producing theirs, either.” Needless to say, the dragons woke up.

Not all hopes come true. I have a good friend who worked as a process and quality auditor in a company that valued process less and less over the years. When her department was outsourced to a process oriented consulting firm her hopes soared. Finally the cavalry had arrived. Unfortunately the cavalry struggled with the same management issues she did. Management was slow to see the benefits of process and always tried to drop it. Rather than despair, the group aimed high, worked hard and lowered their expectations.

If you don’t want to milk cows for the rest of your life, don’t learn how. This was a bit of wisdom my grandmother used to tell my mother. Granted, there are aspects of your job that aren’t enjoyable but still need to be done. However, there are other things that probably don’t make sense for you to take on. SAS programming is a good example. Yes, it is still around. There may be a need for some simple SAS reports, but unless you want to be the one everyone goes to for SAS you might want to find someone else to do it and claim ignorance.

Hopefully you can take these lessons to heart and not have to stub your toe on them yourself.

If you have experience from the school of hard knocks, weigh in with a comment and help us all get a little wiser.

March 19 – Employee Recognition

After growing up about south of Buffalo, spending eight winters in Cleveland and one in Syracuse, I know what winter is like. It makes you appreciate spring more. You can tell spring is coming because crocuses and daffodils begin pushing up through the snow. It is a refreshing sight after several bleak months. Like those flowers, there are signs that herald improvements in the job market. One of those indications is that companies start taking about Employee Recognition. When resources start disappearing to other companies, employers start appreciating those that are left.

There are many forms of recognition for both individuals and teams. Here are a couple of ideas.

Individual:
Public recognition. Stand them up in front of the team and give out awards. It may be as a paper certificate or a medal of honor. The idea is to let them know that you like what they did. Assuming the rewards are administered fairly, recognizing high achievers can also encourage the rest of the team to better performance.

Cash. Few people are beyond enjoying a little extra spending money.

More interesting assignments. Good resources should get the opportunity to work on better projects. If they are stuck doing the grunt work all the time they will eventually get burnt out and stop producing.

Team:
Lunch. I’m a big fan of celebrating project completions. Lunch at a decent restaurant or even catering it in to a conference room is a great way to show the team you appreciate them.

Upper Management Accolades. Projects are started with a purpose in mind. Assuming anyone remembers what that was for your project, let upper management know that you accomplished it. Help them see the significance of it and allow them the opportunity to give kudos to the team.

Compared to hiring new people and bringing them up to speed, recognition is really inexpensive. I have a friend who applies this concept to his marriage. He claims it is “cheaper to keeper her.” Considering most divorces end with the lawyers getting everything, he’s probably right.

As a project manager it is your responsibility to take care of your team. Find out what opportunities exist within your company to recognize your team members. Fill out the necessary forms and get the business to admit nice things about them. If there aren’t any recognition programs, work with your HR team to develop some of the ideas listed above or make up your own.

March 15 – Email Problems

Register @ Cutting's Edge for a chance to win a copy of my new booklet 30 Days on the Cutting's Edge Volume 1.

To some email is a necessary evil. To others it is the golden form of communication. From passing pictures of your pet to receiving approvals from your sponsor, email is a major part of our world. The trouble is there are a few things you need to avoid when using it.

Hiding. Email is simply a communication tool along with the phone and face-to-face meetings. If you are sending emails because you are avoiding a discussion that should take place in person then you are hiding. Get out from behind the screen and start talking.

Poor Naming. There are 3 things to avoid with the name. First, don’t forget to put a subject on the email. Second, don’t use a subject that could get blocked by spam. Finally, don’t get ignored. Give it a subject that will get the reaction you are looking for. If you need them to do something add ACTION REQUIRED to the start of your title. If it is acceptance management start with APPROVAL REQUEST. Use a title that explains the email and will get it read.

Mad Mailing. I have typed some emails that would have been career-shortening events if I hadn’t hit the delete button. Never send an email in the heat of the moment. Carefully save it as draft so you don’t send it. Go get a cup of your favorite, legal work beverage and come back to reconsider it. If you are still ticked, print it and have someone else read it to talk you down. Sometimes it is very therapeutic to vent but do so safely.

Spell Checking. Definitely use spell checking. One of my all time really bad jokes is “Bad spellers of the world, UNTIE!” Usually I have to explain that “untie” is “unite” spelled wrong which just ruins the whole affect. But use spell check wisely, especially with names. If you don’t Waithe becomes Waiter, Uwins becomes Wines and Shashank becomes Sheepshank. Not very pretty. My favorite example of spell check problems came from a woman I worked with once. (It’s ok, Judy, I won’t mention your name). She wrote an email about Sarbanes-Oxley and spell check changed it to Sardines-Ox eyes. She sent it before she saw it.

Not Reading. Before you send it, give it one last read. So often I look at something I have written and wonder how I expected anyone to possibly understand it. I also use spell checking as my last line of defense against a bad email. If it catches a word, I take a moment longer to consider whether to send it or not. Several times I have opted for phoning or going to see them person instead. More often I have chosen to reword the whole thing or drop it all together.

CCing. The entire company doesn’t need to get all of your emails. Does that long list of individuals on the TO and CC lines have to be there? What is your purpose for including each one? Many of them probably won’t even read it. I had a manager once who said because of the number of emails she received she never opens those that she was cc’d on. That explained why I never received the support I expected from her.

Email is just another tool in your bag. Use it for good and not evil.


Don't forget to register @ Cutting's Edge.

March 15, 2007 – Wowing Management

Register @ Cutting's Edge.

I heard an interesting quote the other day: “Desire without dedication is fantasy.” It was said in the context of maintaining a solid marriage, but it struck me that it was such a universal truth. If an athlete desires to be a professional but lacks the dedication to practice he is just dreaming. A farmer that wishes to have a good crop doesn’t lay around all spring thinking about it. It seems obvious in those contexts, yet it seems to fall apart in the world of management.

Many times management recognizes the need for establishing guidelines and following best practices but lacks the will to follow through with it. They get a glimpse of what consistent processes can do for them but can’t or won’t enforce them long enough to see the benefit. Granted, if it were easy everyone would do it.

I always enjoy starting in an environment where there is a lack of project management processes. It is fun to wow people with the simple things when they haven’t seen much real project management. Here are a few simple actions you can take as a professional project manager to impress your management.

Meeting Minutes. One of the simplest steps to project success is issuing minutes from meetings. It is also one of the things many project managers drop first. Minutes refresh attendee’s memories, inform those that weren’t there and give everyone a chance to confirm agreement with what happened. Good: Include a list of invitees and mark off those that show up. Better: Keep the minutes short. Give decisions, not discussions. Best: Publish them within 24 hours. Great: Use the minutes template as the agenda and send a draft version with the invitation.

Project Tracking. Use your project schedule don’t just look at it. Set it up with realistic estimates and time lines and keep it updated throughout the project. Good: Track the actual time expended (Actuals) and reforecast with the Estimates to Complete (ETCs). Better: Identify and manage the critical path. Best: Baseline to your budget and track and use Earned Value to manage the project.

Status Reporting. One of the basic communication elements, the status report is a clear, concise summary of what happened in the last week. Good: Add a section describing what to expect this week. Better: Include Risks and Issues. Best: Give the high-level project schedule indicating if you are on schedule/budget. Great: Use Earned Value statistics to show trending.

Status Meetings. Don’t just send the status report. Schedule a weekly meeting to review the status of the project with the Sponsor. It doesn’t have to be a long drawn out event. Good: Pick out the highlights from the report that will keep her informed of the project. Better: Discuss risks and issues and explain how management can help mitigate and resolve them. Best: If you don’t have an answer to a question, admit it, get the answer and get back to her.

If you can do these four things consistently you will not only wow everyone, you will deliver your project successfully and without any surprises.

March 14, 2007 – What’s in a Name?

Register @ Cutting's Edge.

Training classes and conference presentations tend to have bizarre names to attract people to them. They are like shiny objects to kids. I’ll admit, I am guilty of this. Some of the names for my articles and presentations include “The End of Fairy Tale Beginnings,” “Piñata Management” and “Avoiding Shock Therapy” (see Cuttings Edge Presentations). The term coined for these types of presentations is "Edu-tainment."

The list of classes that follows is from a 2005 Learning Center Programs catalog for a major company. The descriptions, however, are merely my guesses at what might be taught in such a class.

Embracing Chaos – This 6-hour course give you the structured tools necessary to truly define and order your chaos. Using the principals of the Chaos Theory this class will start bad and get worse.

Thriving on Chaos – Learn proven techniques to use chaos as a cover for you agenda and 10 steps to overpower co-workers.

Guiding Employees through Change and Survival Skills – Based on the hit TV series Survivor, your employees will learn how to lie, cheat, back stab and form alliance in an attempt to stay on the company island.

Bad Apples: How to Deal with Difficult Attitudes – Eight simple words to help your team deal: “I have a bad attitude. Deal with it.”

Between You and Me: Solving Conflict – For those students that need a remedial class or have failed the Bad Apples session. Students will be asked to step outside and supply their own bandages.

Making Your Point without Saying a Word – This business course includes sign language and facial expressions to express both sarcastic and derogatory comments.

Comfort Zones – Sponsored by La-Z-Boy furniture, students learn the ability to appear as if they are working while taking a nap at their desk.

Communicating With Your Manager – This advanced topics class focuses on speaking slower, using smaller words and drawing lots of pictures.

Dealing with Difficult People – 7 steps to becoming difficult yourself and forcing others to attend this class to deal with you.

Dealing with Different Personalities – Especially useful for those project managers that have multiple personalities.

I’m sure these classes offer exciting insights into their particular topic or the company wouldn’t have selected them. Admit it, you would be more likely to attend these than “Performance Appraisals and Basics of Interviewing,” right?

March 12, 2007 – Nailing It

Register @ Cutting's Edge.

I spent Sunday afternoon working with the HOGs (Handymen Of God) group at church to construct a set of stairs and a couple of risers. HOGs is a group of men that take care of odd jobs for widows and elderly couples. We do real “manly” stuff with wood, power tools and pizza. My dad used to say to me, “you hammer like lightning because you never strike twice in the same spot.” Hopefully I am better at project management than swinging a hammer.

Yesterday several great construction sayings were bantered about and, of course, I found them very appropriate for project management.

Measure Twice Cut Once. This quote from Bob Vila’s This Old House fame cuts too close for comfort. It applies to so many different areas, too. The obvious application of this would be to talk about planning and how it can save so much effort later. But I’ve decided to apply it to emails. I have learned to leave spell checker all the time and reread everything before I press send. Just last week I typed someone’s name into the CC area so I could verify the spelling. Of course I forgot to delete it out before hitting send. Fortunately the email put her in a good light.

When you only have a hammer, all your problems look like nails. I have seen people actually put screws in with a hammer because their screwdriver wasn’t handy. You can actually make the word “n-a-i-l” from the letters in “individual” but that doesn’t mean they will all respond well to the hammer. You need to determine what motivates each one and I don’t suggest using a vice.

If at first you don’t succeed, get a bigger hammer. This may seem to counter the previous saying, but sometimes it does come down to brut strength. Whether that is pulling an all-nighter to fix a problem or escalating an issue to upper management, some things can’t be resolved without that extra push.

Most project managers don’t run the risk of loosing a limb to a power tool, but if you are not careful you could get a paper cut or two.

March 9, 2007 – Project Management Inside the 18

Register @ Guest Book

In soccer, the term “18” refers to the penalty area where the dimensions are 18’ from the goal posts on all sides. It is the home of the goalkeeper. Many years and pounds ago, I was keeper for both my high school and college teams. Now my daughter is learning to play for her team. As I am teaching her how to cut down the angles, dive and protect the ball, I realized that there are many parallels between the role of a goalie and a project manager. I’ll bypass the analogies about getting kicked and shot at and give you 5 practical ways to win.

Keep you head in the game. Soccer is a fast paced game. One minute the ball is on the other third of the field and with one swift kick you are under attack. As a project manager you need to keep focused and looking for threats or risks to both the project and your team.

Set the tone of the game. Team members sometimes start to play reactionary ball and begin to take out their frustration on the referees, the other team and sometimes even on their own players. It is the job of the goalie to bring them back and refocus them on the game. Your project team may get distracted by politics, mistakes or difficulties. You will need to step in and settle them down so they can refocus on the tasks at hand.

Give direction. The best tool a goalie has is not his hands. It is his voice. A good goalie will direct his defense to pick up unmarked opponents, build a wall and start an attack. He doesn’t tell them how to kick the ball, pass or dribble. The players have the skills but the goalie can see more of the field and offer direction. That is your job, too.

Encourage the team. If the goalie spent all game yelling directions at the team they would soon start yelling back. An “excellent clear,” “great hustle” or “nice stick” goes a long way to keeping the team’s energy up. You need to do the same with your resources. Catch them doing something well and then let them know you saw it. Find out what opportunities your company gives to recognize individuals. Upon completion of the project or a particularly tough stretch take them out to lunch.

Be the last line of defense. Ultimately the goalie’s job is to keep the ball out of the net. When your team is under attack from upper management or other groups, it is your responsibility to stand in and take it for the team. Certainly if they have messed up there should be consequences, but their protection is your concern.

Did I tell you that the goalie is the one that tends to get the most bruises? Or the fact that I still have a scar over my right eye where I took a cleat to the head? Probably better if I don’t mention it, eh?

Have a great game!

March 8, 2007 – Project Definition Trio

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive updates from the Cutting's Edge.]

Project definition is a tricky part of the project. If your environment is like most, you need to nail down the scope, the responsibilities and the approach as quickly as possible because the team has already started working. Given the limited time it may sound counterproductive but ideally you should create the preliminary list of risks and the project schedule at the same time.

As the image above illustrates, the Project Plan* (Scope, Management Plans, etc.), Schedule and Risks feed off each other as they are created. As the Scope Statement is defined and activities are defined they are added to the schedule. When an item is determined to be someone else’s responsibility there is a risk that it won’t be done.

While developing the Work Breakdown Structure (WBS) and Project Schedule you will uncover activities and perhaps deliverables that need to be added to the scope. Thinking through the implications of the tasks involved may trigger a thought for the Quality Plan or identify a new role to add to the Human Resource Management Plan. Risks are a natural result of drilling into the details.

Identifying Risks may expose the need for additional communication channels, tasks in the schedule or clarifications on the scope.

Working these three tools together will set your project on the right track from the beginning.

* Per PMI definition the Project Plan includes the Scope Statement, Risk Management Plan, Quality Plan, etc. The Project Plan could also be replaced with the Statement of Work (SOW).

March 7, 2007 – Deliverable-based Project Schedules: Part 7

Finally! We are ready to add resources and get on with the project.

Assign Resources. Just do it. Make sure at least 1 resource is assigned to each task and turn them loose. There are 2 tips I would throw out, though.

First, as I mentioned before, assign the resources 100% to your project unless they are physically on a different project for a set amount of time. This gives your scheduling tool the most options when calculating assignments.

Second, enter dollar values for your resources. If you are not tracking the value of your project you are not effectively managing your resources. A blended rate doesn’t truly cut it. If everyone cost you the same for your project wouldn’t you always pick the best ones? Think about professional soccer. What if you could get David Beckham or Tom Cutting for the same price? Not really a question, eh? My point is that each resource brings different strengths and different expenses to the mix. If you have a budget you need to balance both sides of the equation.

Add Constraints. Once you have the resources entered the final step in setting up the plan is adding the constraints. This includes updating the scheduler’s calendar with holidays, filling in vacation time, setting target dates with milestones, etc.

Wow. You have officially created the first pass at a deliverable-based project schedule. Which, of course, means it is scheduled for twice as long as you have and three times the budget. Now you need to go back and balance the resources, adjust the dependencies and make modifications to bring it into alignment with reality. But, these are all great topics for another day.

Before we run off, though, let’s recap. The objective was to build a plan based on deliverables. All of the tasks role up into one of the deliverable. Because we applied the 80% productivity factor we have a realistic view of the length of the project. We even added cost to the resources.
Assuming you baseline the original schedule and track it with Actuals and Estimates to Complete you can accurately report progress and project completion for each deliverable. Add columns to display the baseline and planned values for the start / end dates and costs and you can tell if you are within schedule and budget. This is the information management needs to determine the health of your project.

When is enough too much? We touched briefly on this when we were breaking down the tasks. The level of detail and amount of tracking you perform should be comparable to the amount of benefit you gain from it. If no one cares if you finish on time or within budget, then why bother tracking? Enough becomes too much when the effort outweighs the benefit gained from doing it.

March 6, 2007 – Deliverable-based Project Schedules: Part 6

All the tasks have been laid out, sorted into deliverables, aligned with predecessors and estimated for effort. If you are using an auto-scheduling tool like MS Project, the length of the project has been stretched out as if one person was doing everything at 100%. Now we want to set realistic expectations on the duration of each task.

Estimate Duration. “Why are we worried about the duration before we add the resources?” you might ask. Good question. The reason is productivity. It is easier to bake it in up front than to try and force it in later.

Mentally everyone knows that, unless you work overtime, an 8-hour task takes more than a day to complete. This is a factor of our productivity. Over the course of a year people are, at most, about 80% productive. This is based on the following calculation.
2080 hours in a year (52 weeks * 40 hours / week)
- 72 hours for holidays
- 80 hours vacation
- 48 hours sick time
- 24 hours training (non-project related)
- 52 hours status reporting (1 hour / week)
- 52 hours team meetings (1 hour / week)
- 88 hours interruption (1.5 hours / week)
1664 hours remaining (80%).

Obviously some people have more vacation, others don’t get sick, some have more training, etc. but in general this holds true. Without taking this into account at the task level you are setting yourself up to be late.

Some project managers do this by assigning all of their resources at 80% available. In MS Project there is a resource field named Max Units that they set to account for the productivity factor. Unless someone is assigned to my project only part time, I keep them at 100% available and set the duration of the individual tasks to account for the extra time. After all, they are still expected to work 100% of the time.

MS Project allows you use a custom field to automatically calculate the 80% rule. To do this use the Duration 1 field and create the formula [Work / 0.8]. This will calculate 8 hours as 1.25 days and 40 hours to be 6.25 days. If you place the Duration 1 column in the schedule beside Duration, you can easily copy and paste the estimated values into the Duration column.

You can also type it manually for each task using the 8 and 40-hour duration estimates as guidelines.

When we add multiple resources to a task, they are each assigned at 80% to it. They will still be assigned 40 hours of effort for the week, but the tasks will be spaced to account for interruptions, status reporting, overlapping tasks, etc.
The resulting durations are starting points. After you add resources and begin to use and refine your schedule you can make adjustments to them.

March 5, 2007 – Deliverable-based Project Schedules: Fixed Work Sidebar

Before we move on to discussing duration and adding resources there is a side step we need to take to discuss different task types. When you are developing your project schedule, most tasks should be set as Fixed Work. As effort is expended or added to the task this allows the tool to re-calculate the duration and show the new estimated completion date.

In MS Project there are 3 types of tasks: Fixed Duration, Fixed Units and Fixed Work. I’m sure other scheduling tools have similar terms. Units (U) refers to the percent a resource is assigned to the task (the productivity factor discussed above). Duration (D) is the number of days a task takes to complete. Work (W) is the amount of effort expended or to be expended on the task. The formula for calculating Duration is D = W / U (ex. 8 hours / 80% = 10 hours = 1.25 days). This equation and variables are used to determine when the task will complete.

“Fixing” one of these variables tells the tool not to allow it to change. If Duration is fixed and you add more Work, the Units will increase to balance the equation. In order to complete a 16-hour task in 1 day the resource will need to be assigned 200%. If Units are fixed at 100%, reducing the Duration of a 16-hour task from 2 days to 1 day will force the Work to 8 hours in order to maintain the equation. Neither one of these options helps you track progress.

Selecting Fixed Work is more realistic. If you have an 8-hour task scheduled for 1 day and you decide to extend it to 2 days you want the Work to remain at 8 hours, not increase to 16. The time you allowed for the completion of the task increased, not the effort to do it.

This is a big topic from project managers trying to figure out what MS Project is doing to them. They change a duration or end date and suddenly the estimated hours either explode or shrink to nothing. Very frustrating.

On the flip side, there are tasks that should be Fixed Duration. These tasks include support, status reporting and others that are based on the calendar rather than the effort. Although I have never used it, there is probably a good application for Fixed Units. If you have an example, add a comment to this blog and I’ll pass it on.

The task type becomes important as we move to estimating the duration.

March 2, 2007 – Deliverable-based Project Schedules: Part 5

With all the tasks defined and even divided up into deliverable many project managers would be off and running. Truth be told, projects can be successful with the checklist approach. The trouble is a checklist does not allow you to predict when deliverables will be completed, report on the true cost of the project or understand and impact the critical path. I suggest we keep pushing forward, then.

Determine Predecessors. When you are setting up your project schedule, enter the logical predecessors. These are the tasks that legitimately belong linked, like creating the document before you review it and ordering the hardware before you receive and install it. Fake predecessors are based on resource availability or just a random decision because something has to go first. These have their place throughout the project, but not when you are initially setting up the schedule.

The more tasks you can link with predecessors the better your scheduling tool can… well… schedule.

Estimate the Work. You may have noticed we haven’t assigned any resources yet. As you estimate the work for each task, think in terms of 1 person doing the work on that task uninterrupted. So, even if you anticipate it would take 2 people a week to complete a document, set the Work value to 80 hrs. Later we will add the specific resources.

While you are assigning the Work, you are probably thinking of a certain skill level or specific individual. These thoughts influence the estimate. Because of this you should document them as estimating assumptions and include them as part of your proposed schedule. No, this isn’t a fancy word for excuses. If you are expecting an expert Java programmer and end up with a novice, your assumptions were wrong and therefore your estimate will be off. With your estimating assumptions outlined you can recognize the impact and make adjustments accordingly (i.e. more or different resources, additional training, obtain more time, etc.).

March 1, 2007 – Deliverable-based Project Schedules: Part 4

Whether you select a Product or Phase structure, the steps to building a deliverable-based schedule remain the same.

Enter All Tasks. The next step is to fill in all of the tasks associated with the identified list of deliverables. Those deliverables may be the list from the WBS or, like the Phase structured schedule; it may include the separate building blocks (i.e. Requirements Document, etc.).

Drill down to the task level for each deliverables. You can use the WBS or other tool, but eventually you will need to switch to the scheduling tool. Although we are not ready to assign effort to the tasks, the general rule of thumb for the size of a task is between 4 and 80 hours per resources. Anything less than 4 hours is a pain to track and doesn’t offer much payback for the effort. Anything greater than 80 hours is hard to grasp. We are pretty good at understanding and estimating things that can be done in 2 uninterrupted weeks (= 80 hrs). Anything larger becomes difficult to estimate and should be broken into smaller pieces.

Each deliverable should be reviewed with the group or at least the individual that will approve it so include the task Review Deliverable and the milestone Obtain Approval for each one. (Note: a milestone is a task with zero hours and zero duration used to mark an important event or accomplishment.)

Add another deliverable at the bottom of the schedule for Project Management. The tasks under it should include Project Status Reporting, Individual Status Reporting & Time Keeping, Team Meetings, Client Meetings and Management. Some people track project management time as part of each deliverable but it is easier and cleaner to pull it out as a separate item.

The ultimate goal is to have all of the tasks neatly tucked in as sub-tasks under one of the deliverables. Collectively the deliverables constitute the whole of your project scope and anything not part of a deliverable would then be out of scope. However, as you complete your list of tasks, there will be some that don’t seem to fit. There are several possible reasons for this:
1. A deliverable has been missed. Something needs to be added to the scope of the project. If the scope has been agreed to you may need a change request to add to it.
2. The task might have been dumped on you when it should really be out of scope. This might require some push back to define your responsibilities.
3. It may be a legitimate task but the responsibility of another group. You may want to track the completion of the task but not the effort.
4. The process or lifecycle may require the task (ex. creating internal assessment documents, updating review committee checklists, etc.). Since the deliverable is a product of the process, these types of tasks can be incorporated into its creation.
You may have to get a little creative with some tasks, but to effectively use the project schedule to track and report progress you don’t want a rambling task list with no structure.