Author: Kevin Watson
With over 25 years of project management experience, Kevin Watson, PMP, MCT, MCTS, is a black belt in Microsoft Project and Microsoft Project Server. Kevin brings a unique combination of project management and project server to the field, where he is a Senior Consultant with Microsoft. Contact him at kevinw@microsoft.com.
The Swiss Army Knife Approach to PPM Solutions
While I traveled through the Shannon Airport as a boy in 1969, I remember well my enamored gaze into the display case of the Swiss army knives. “Dad, can I have one?” I asked. I got the usual parental questioning. “Are you sure you are mature and responsible enough to have one?” Being only 10 and not as wise as I thought I was, of course I responded with a resounding YES. However, I quickly found out my thumbnails and fingers were not developed enough even to open many of the different tools. I recall being cut and poked as I tried to open up every tool, occasionally even deploying the help of another screw driver. As I’ve gotten older, I’ve realized deploying Portfolio and Project Management (PPM) solutions are a lot like this… Many of our customers also have that little boy, wide-eyed excitement look on their faces when we demo Project Server, and lack the maturity to know any better. “Yes! Our project managers are all PMP certified,” is what we usually hear when we ask if they are ready to use such a multi-packed tool set. And we have all clearly seen that they soon all fall short of the mark. PPM raises the bar and exposes the reality of their current understanding and expertise in building good, sound schedules. I prefer we focus on building a solid foundation for the customer to build their deployments on. First goal: Get a list of projects into the system and validate them with reports. Just as in building a skyscraper, they first pour the footing, test the concrete as they pour it and wait for it to set then, test it again before anything is built on it. This has to be part of the message up front when selling the solution; we have all seen clients get all the little tools out, attempt to use the knife, and end up hurting themselves. We start by only teaching them how to open the screwdriver, and when – and only when – they have that down do we teach them another feature. The foundation has to be a good schedule (good data). Adding highly effective training courses like “Dynamic”, “Forecast” or “TJYJ” training should also be proposed in every offering. If not, I am confident they will come to their own conclusion that it is needed once they see what they have published in an enterprise environment for the first time.. We should all have conversations about what to stub out plumbing-wise (hardware/services) before we pour the slab. Trust me – it is not fun to try to put a bathroom in your basement when the floor is already poured…
Are You Smarter than a PMP?
Part One Here is a challenge for you, in this article I will ask you perform a simple task, in the next I will provide the answer. Your organization wants to do resource capacity management. Your task is to open Microsoft Project 2010, create a single task for a “Status Meeting”, and if not in auto schedule mode please ensure it is for the task. Now assign three resources to the task. Save the project file where you can find it and catch the next newsletter for the answer. Thanks all this is to it. See the next newsletter to see how you did. Results may vary but many of you may be surprised with the results. Part Two Last newsletter I offered a challenge to the MPUG community. Now you will have the opportunity to see how you did. Open the project file you saved from part one. Insert the work column next to the duration column if it’s not there already. Now here is where it gets interesting, what do you see for the value found in the work column? Assuming most of you typically only schedule a status meeting for one hour, what value would you expect to see in “work”? The results I see more often than not with many PMs is “24 hrs.”. Why is that you might ask? Well if you use project like most people right out of the box and you don’t know what task types are (see “The Seven deadly Sins of Project Scheduling”) then this is how you got there. Recall that I said your organization hopes to do resource capacity management. Imagine if you will that other PMs also follow down this track and schedule a resource for a status meeting at 8 hours for the day or any other task assignments. Pretty soon when you attempt to see if a resource is available you will find they are showing far more hours assigned in a day than exist in a day. Fundamentally and sad as it may be I see way too often. This multiplied effect is particularly damaging and evident when you are using project server or a shared resource pool. Resource capacity management is impossible when you have incorrectly assigned work to resources. When I pointed this out to a group of PMs the error of their ways I heard…”Well I am not a PMP” hence the title of my series. The correct number of hours one should see when done properly would be 3 hours. One hour for each resource times 3 people. I ask the question from PM audiences all the time “What are task types?”, it’s not very often I get a correct answer. Project can be your friend or enemy depending on how well you know it and use it. As I like to say all the time, “the tool is as only as good as the data that goes into it”.
The Seven Deadly Sins of Project Schedules
Scheduling is never a simple component of a project; yet in the last 20 years I’ve repeatedly run into the same basic problems in every organization I have worked for or consulted with regarding their schedules. Here I lay out the seven deadly sins of project schedules and provide you with some antidotes. My hope is that you’ll use this advice to lay the right foundation for successful project management when using schedules. Sin #1: The schedule is too complex! When you have schedule that has more lines running north to south than left to right, you have a problem. If it takes weeks or days for stakeholders to understand your schedule, then the model is too complex. If it’s too difficult to explain to executives or even to your team, then how can you expect anyone to benefit from it? How do you know if your project is too complex Ask yourself how easy it is to find the critical path in your schedule… Sin #2: Your schedule has too many tasks This more than anything will contribute to why schedules fall by the wayside. Project managers somehow get the impression that a schedule needs to be a checklist of everything that needs to get done. To-do items and reminders-to-self don’t belong in a work breakdown structure. This approach completely defeats the whole purpose of a schedule representing a model of your project. To illustrate the point, let me share an example. Consider that you’re the lumber supply person or the framer who will be erecting a house being built. You need to know when to deliver your lumber package or show up with your crew to start work. This typically occurs when the foundation is complete. You can build a schedule like this… Or one like this… If you were the builder and scheduler, which approach would you prefer to have to update and maintain your actuals Imagine that you had 30 houses under construction at the same time. Which would you prefer? That is not to say that all the other tasks listed aren’t important or don’t need to be done; the real question here is how to track and maintain it? You could also just list the detail tasks as a note to the one line task shown above. Here’s my rule of thumb, which I take from Eric Uyttewaal’s book, Forecast Scheduling with Microsoft Project 2010: The minimum duration is one percent of the project duration. The maximum is 10 percent of the duration. Sin #3: Your network logic is incomplete or isn’t dynamic Incomplete network logic is the number one reason why schedules fail to forecast properly or evolve dynamically. Too few dependencies account for this. Use of too many constraints will also greatly impair the dynamic nature of a properly laid out network. If you see mostly constraints in the indicator column, this indicates you may not really know what you’re doing. Project managers often make it a point to hide this column in order to hide that they have many constraints in their schedule. Here’s an easy test for you. Find the critical path in your schedule (if you can’t, you already have a major problem), then take one of the longest incomplete tasks early in your schedule and double the duration. Does your project finish date change? If not, then you don’t have a working schedule. You won’t be able to benefit from the basic tenants of having a dynamic schedule that you can use to forecast tasks and timeframes and for you as project manager to control the results better. Sin #4: Your schedule isn’t baselined Not baselining a schedule will make it difficult if not impossible to measure variance. Baselining helps to capture your schedule before you begin work and allows you to learn from the variances when reality sets in. If you can’t measure it, then you can’t control it. Sin #5: Your schedule doesn’t get updated The vast majority of the schedules I have seen are out of date. Project managers will often abandon the schedule once the project is underway and find themselves fighting fires while in execution. The likelihood of this happening increases significantly if the schedule was too detailed and required too much work to keep it up to date. The bottom line: If you don’t update your schedule, then you have lost your ability to forecast future dates. Sin #6: Your schedule has no resource assignments or they’re over allocated Often schedules are created without any resource assignments at all. This might make for a nice picture that may give the false impression that the timeline is attainable. If resources are added and then leveled, an entirely different timeline may emerge. When resources are assigned, more often than not when looking “under the hood” (using resource usage view), they’re grossly over allocated. If you start with out-of-the-box fixed units, you’ll be starting off on the wrong foot. Take the time to evaluate whether you’ve made realistic assignments in terms of time and work allocated within a person’s capacity. Also, show extreme caution when using the auto resource leveling feature. It’s best used in manual mode. And using an enterprise solution that gives you visibility into other project workloads should increase your confidence that tasks can get done. Sin #7: You don’t know what task types are If you don’t understand how the project scheduling engine works and how task types work in the following equation: Duration * Units = Work you will be forever pulling out your hair and getting frustrated with the tool. If you find yourself not getting the message, then I recommend you get yourself a good resource and study it. Forecast Scheduling with Microsoft Project 2010 is a good place to start.
How to Restore an Abandoned Project Schedule
Ever known someone with a once-beautiful old car that’s been left to rust away — their once prized possession now forgotten in the weeds? Often, a project manager’s schedules succumb to a similar fate. Consider what would happen if you were to tow that car out of the weeds and take on the project of restoring it. Once restored, it would be very valuable, indeed — a vehicle you’d be proud to own and drive. Reworking and restoring a project schedule, the vehicle that moves the project along, can be similarly rewarding. In this article I share basic steps for picking up an abandoned project and restoring it. Examine the Logic of the Project First, you’ll want to take an inventory of what you have. Open your schedule and really look at it. Far too often, owners of schedules treat them like spreadsheets, never expanding the view over to the right to include the Gantt view. They’re caught up in the numbers and dates, failing to look at the logical flow and relationships. Try rolling the sections up to highest level and begin to expand each level. Does it make sense? More often than not, what I frequently see at this point are more lines going up and down than left to right, in some cases almost completely covering up the Gantt bars (as shown in Figure 1). Figure 1. An example of the “bar code” project schedule. This is what I like to call a “bar code.” I even had one client who tried to scan it thinking perhaps some higher power was at play sending a message of pending doom or that there was some hidden master plot to sabotage the project. This generally crops up with schedule owners who know just enough to be dangerous. They’ve heard that constraints can be bad; so in an attempt to avoid these, they manipulate the links tying everything back to anchor dates (usually the start) while abusing lead and lag in order to force the dates where they think they should be. It has been said that nearly 75 percent of all links in most schedules are redundant in nature. If your schedule looks like this, its time to strip the whole thing down to each individual part, just like when you restore an antique car. Remove the rust, moss, and weeds by deleting many of the relationships. Now its time to reexamine each part. Do the hours, durations, and resources make sense? Do these need to be revised More often than not, they do. Time is your friend here. Think about what you’ve learned from the onset of the project. Now is the time to start applying some of that hindsight. Peel Back Resource Assignments Over-allocation is another area to scrutinize. This can potentially be even worse if you’re working in an enterprise environment. Switch to the resource usage view and change the time scale to weeks or months. Look for the weeks or months that show up in red. Many people get too carried away here trying to solve at too granular a level. If you see one week with 60 hours followed by one with 20 hours, for example, its best to assume some averaging will occur. Resources will work according to their schedule rather than some mandate your schedule has assigned to them. Theyre likely smarter than we give them credit for. Most people get themselves into trouble from the very start by using the default, out of the box task type (Fixed Units). When you assign by this method, everything is assigned at 100 percent. Before long, you have a resource assigned more than a thousand hours in a month. Given that the average work month is around 160 hours, how do you imagine the work will get done? Short of being able to instantly clone people, its not going to work. Here’s something else to consider. Who works on only one task at a time, 100 percent of the time? I don’t know anyone who does, so why assign work that way A better way is to use fixed duration, non-effort driven. You can always change it after the schedule is complete. Most people can estimate how many hours something will take. Keep in mind; your resources more than likely have other things they’ll be doing already, so give them more time (duration) to get work accomplished. Let Project do its job and calculate units. If you did a good job, you should see something, I’d hope, less than 75 percent units at most. This amounts to about 30 hours a week which, with everything else on someones plate, is a reasonable number provided they have no other major assignments at the same time. In summary, always book your resources to less than 100 percent units. Last Step: Reassembly After you’ve cleaned up each task, begin reassembling the pieces starting with the highest level first and working your way down to the lowest level. Last but not least, be sure to reschedule your unfinished work and update your schedule to current status date. Figure 2. The same project’s summary outline, after restoration. Reworking your project schedule by completing these steps will reward you with a beautifully restored vehicle you can proudly drive around the organization.