Archive for the ‘Project Rules’ Category

Lost with Confidence! 5 Thoughts about Baselines

March 31st, 2014    Posted in Project Rules
 

On a trip to Paris, I headed away from, instead of toward, the Seine River and wound up elsewhere. A little freaked, my wife panicked and started to worry about our safety. My reply was simple, “Be lost with confidence and no one will bug us.” Working on a project without a baseline is like being lost with confidence. While the day in Paris was an unexpected surprise, project managers need to minimize unexpected surprises. Below, are my thoughts on baselines.

1. Baseline as a Yard Stick 
A baseline can measure project performance. At the very least, a baseline lets the project manager know if it’s completed on time. At best, it communicates that the project is on time, within budget and that resources are correct.

2. Basis for Restoring the Project Plan 
Most projects have surprises, and how a project manager reacts is in direct proportion to success. A recovery plan that gets the project back in synch, compared to the baseline or original plan, clearly communicates action toward success while creating confidence moving forward. Without a baseline, it seems as if the project plan is be made up along the way.

3. A De facto Baseline 
Owners often approve a baseline, but not really. For a variety of reasons, a baseline sits in an approval queue while the project moves forward. Smart contractors or project managers use the baseline submitted as something to measure against. This becomes a “de facto baseline”. If the contractor has a detailed plan, then the de facto baseline serves the purpose. Moreover, unless the project comes to a complete halt; it can’t wait for an approved baseline.

4. Baselines Support – not Solve – Litigation 
A project baseline is a measuring stick. It can clearly show impacts to the project plan. Yes, schedules are used in court. However, a baseline by itself doesn’t settle a claim. It’s used as an early warning so litigation can be avoided. But once in court, the superintendent’s log is far more valuable.

5. Earned Value Requires A Baseline 
Once a baseline is set, Earned Value Management metrics can be used. These industry standard metrics provide a gauge to how the project is doing. There is no magic “earned value button” in software, but by simply creating a baseline, you can make earned value available. Yes, earned value management is a science, but not rocket science.

I could have used a map in Paris, but for various masculine reasons, I didn’t. A project baseline is the map to project success. It is a guide to provide a true direction for a project. In almost 30 years (I’m ancient) of project management, I would estimate that a little less than half of all projects I worked with set a project baseline at the beginning. Even fewer used a baseline correctly. Too bad; it’s a powerful tool.

No Comments

Projects: Mowing the lawn vs. cutting the grass

June 19th, 2013    Posted in Project Rules
 

My younger brother John used to mow our neighbor, Theo Ferg’s, lawn. One week, John had a football camp to go to so I volunteered to substitute for John. Heck, I needed the money, and he wasn’t home, so I figured we might as well keep it in the family.

After I finished, Theo Ferg (who was like an uncle to me) came over and asked my dad when John was coming back. My dad said, “Next week, why?” Theo Ferg replied, telling him that John mowed the lawn and I merely cut the grass. I didn’t want to ask anyone what he meant, but it stung. So, the next week, I watched John “mow the lawn” and I couldn’t figure out what Theo Ferg meant. We used the same mower, emptied the bag in the same place, and mowed to the same height. The only real difference is that John took longer.

I was stumped, and couldn’t still figure it out, so I pondered who I should ask. My dad already thought I was an idiot, so I couldn’t ask him. When I asked John, his answer was “people like him better,” which didn’t help. So, I swallowed some humble pie and asked Theo Ferg, knowing my uncle would level with me. Theo Ferg replied that we both cut the grass well. But unlike me, John trimmed the bushes, swept the deck, and cleaned up the garage when he finished. John took the initiative to do everything; he didn’t have to be told. It was a life lesson that has bled into everything I’ve done since.

Look at the yard with your projects-not the grass.

When working with customers, it’s not just about the software, costs, resources, timeline, or baseline issues. It’s all of those things—plus the things that our projects touch that we often don’t think about. Too often, we cut the grass in our projects and don’t mow the lawn. Instead of seeing the whole picture, we limit our view to just a slice.

Theo Ferg taught me two life lessons that summer:

  1. Mow the lawn in everything that I do.
  2. Everyone likes my younger brother better than me.

Do you and your team cut the grass or mow the lawn in your projects?

Does everyone like your younger sibling more than you?

No Comments

Sexy Project Management Reporting

June 6th, 2013    Posted in Project Rules
 

Project Management Reporting (PMR) will never teeter on the brink of being X-rated, but it shouldn’t be painfully boring, either. One thing is for certain, though: The planning, timelines and other pertinent information in a project management report, which are critical to the project, need to be effectively communicated to appropriate managers.

My friend Tom talks about “sexy-ing” up reports by making them look attractive. He has a point: when a report is ugly, it’s hard to look past the aesthetics and grasp what (very important) information is being relayed.

So, what can you do to develop sexy reports?

  1. Use color
    Printing or publishing color reports from a PDF file is no longer a technical or expensive problem. Color jumps out and grabs a reader’s attention. For example, red means “critical” for timelines and “alert” for status reports. Remember to include a legend that clearly explains the colors.
  2. Pictures & Diagrams
    The old cliché “a picture is worth a thousand words” is absolutely true. Architectural drawings, equipment diagrams, plot plans and job progress pictures are all helpful visuals to present your report.
    A word of caution, however: Don’t let the pictures get in the way of the important information you’re trying to convey. Although pictures help tell a story and are excellent support components, the key takeaway for managers is the information you’re trying to communicate.
  3. Font Selection
    Try to keep the number of fonts you use in your report to a minimum. In most cases, three fonts is the max. If you divide the report into different levels or section, keep each section’s font in the same family. Also, always use both upper-case and lower-case letters. It’s very difficult to read reports that have all upper-case letters, especially if they have a lot of data.
  4. Paper Size
    Reports should be designed to fit on letter-sized paper. All users have access to a printer that prints on 8.5 by 11-inch paper.
  5. Use Subtotals
    In large reports that contain data, subtotal the results. Most readers want to see the big picture. Then, drill down the details.
  6. Graphics Packages
    When building a “sexy” report, programs that utilize and showcase graphics, like Microsoft PowerPoint, are excellent tools to communicate project data. You can also make far greater presentations with these programs than with many project management tools.
  7. The Truth
    Always reflect the truth in your project reports. The tendency may be to “fudge” or exaggerate information. For instance, no one likes to show that a project is behind schedule. Avoid the temptation! Reports should closely mirror what is in your project management software. The truth will always come out eventually…so don’t lie.

Communication is the most important part of project management and effective PMR will help a project by getting better buy-in and participation.

How do you make your reports informative and sexy?

No Comments

Project Scheduling: Theory Matters

May 7th, 2013    Posted in Project Rules
 

Having a solid grasp on theory is a crucial prerequisite to building successful project schedules.

A real-world example

Alexis, my wife, is an awesome musician. She has won several music competitions, is the official organist for the Gary South Shore Railcats, and played at halftime for the RKO-produced 1988 SuperBowl. She is also an experienced music teacher, and when she conducts lessons, she uses the “classical” method of teaching. The classical method includes teaching young children how to read music, theory, mechanics of piano, scales, and the like.

It is how music has been taught for centuries. Her emphasis on the classical method, and the importance of theory, is her key to success. At first, this challenges the young students, who initially sound awful. There is so much for the student to learn. The violin students in particular sound like they are gutting a cat at first. Arrgghh! Progress seems to take forever, but eventually they improve. For this, eardrums everywhere are grateful.

Many of her students eventually win music awards, earn “first chair” in the high school band or orchestra, participate in a play, or compete in a local talent show. At the same age her students started music lessons using the classical method, many of their friends were taught the Suzuki method by other instructors. The Suzuki method does not start out with theory lessons—instead, students listen to a tape and relate the music to numbers and colors. Although these children sound much better at an early age, they often drop out before they ever learn music theory. The Suzuki method doesn’t stress theory until much later in the learning process. Ultimately, these students who were taught using the Suzuki method struggle or quit, because they did not initially learn the theory behind the instrument.

So, theory’s a pretty big deal.

Theory comes heavily into play when building a project schedule. Typically, a project schedule’s discussion centers on adding activities and building a bar chart. Creating the bar chart is the easy part once you’re finished gathering information. Anyone can build a bar chart without much study of theory. However learning the theory behind project scheduling is important to completely and fully understand your project’s schedule. Understanding how schedule dates are generated is the key to understanding float. Understanding float is the key to properly manage a schedule. Once you start communicating the schedule and giving project team participants solid information, they have a basis upon which make decisions.

Where do you find theory to be important in project management?

No Comments

The importance of the right game plan

April 30th, 2013    Posted in Project Rules
 

One of the keys to a successful project is that the entire project team works from the same playbook. Too often, project managers assume that everyone associated with the project understands exactly what is going on, but this is a dangerous assumption. Although everyone on the project team may have a good idea of what was literally said, contextual misinterpretations can occur. Great projects need a great game plan. Even the best game plan can fail if the players aren’t in sync with each other and playing from the same playbook.

Seem obvious?

Picture this: You’re watching a football game between the Chicago Bears and the Dallas Cowboys, and the Bears run (yet another) play that results in an incomplete pass. John Madden, a famed sports commentator, provided a great example for viewers of the importance of a good breakdown structure with his commentary of this play and the Dallas plays that followed.

In this play, the Bears had successfully driven into the red zone (within the Cowboys 20-yard line). Rick Mirer, Chicago’s quarterback, yelled out an audible at the line of scrimmage (an audible is when the quarterback changes the play). Rickey Proehl, the wide receiver, drifted toward the sideline. John Madden announced that the Bears were going to pass. When the ball was snapped, Rick Mirer threw a perfect pass into the middle of the end zone for Rickey Proehl. Unfortunately for the Bears, Rickey Proehl was waiting for the ball on the left sideline at the two-yard line, so the pass went incomplete. Madden then said, “Both these players are new to the Bears, and they are not in the same playbook. Even though Rick Mirer said ‘pass’, it did not mean the same thing to Rickey Proehl.” Although both players were experienced veterans, they didn’t have the same definition of the word “pass.”

On the ensuing series, the Cowboys scored a touchdown. This was greatly aided by a 58-yard pass play that the Cowboys’ quarterback, Troy Aikman, had successfully audibled to his receiver. After the play, John Madden commented, “Those two guys are in the same playbook. When Aikman said ‘pass’, Irvin knew exactly what he meant.”

This concept applies to all projects, project plans, and project teams. The success of the Cowboys (and the lack thereof for the Bears) demonstrates the importance of making sure that everyone plays from the same playbook.

Structure your project “plays”

Although a good breakdown structure ensures that everyone is in the same playbook, it requires more allocated time in your project schedule. It also means you should touch base with everyone connected to the project about how they view the project, and how they plan to coordinate with each other to execute its activities. This allows the project manager to reflect on the various mindsets, and incorporate any differing perspectives regarding the project into the breakdown.

If this reflection doesn’t occur in the beginning stages of a project, the project manager is doomed to try and do the breakdown in the middle of the project. This spells disaster, because it inevitably requires a restructure of the project schedule. It is impossible to find a project manager that has the time to do this, let alone think about it when in the trenches of executing and managing the project.

How do you make sure your project team plays from the same playbook?

No Comments

Project Rule 73: Recognize the security of atrophy

April 16th, 2013    Posted in Project Rules
 

Job security and impact on salary are the most important parts to understanding change management. Virtually all employee motivation is derived from these two basic components. Other motivators include making a job easier and chance for promotion. Read more

No Comments