The Project Notebook

Just Think of all the Money That We’ve Saved!

By: Susan Peterson, M.B.A., PMP
Copyright 2013, Susan Peterson, All Rights Reserved
No part of this article may be used or reproduced in any manner whatsoever without written permission of the author.

Organizations continue to enforce relentless cost reduction efforts in the face of global competition. Given the emphasis on minimizing costs, virtually every project manager has had at least one project budget that is woefully inadequate. After so many years of hearing “less is more”, “lean and mean”, and other well-worn clichés, project managers have come to expect that initial budgets will seldom be realistic to achieve expectations. This article explores some legal “creative financing” options to address the challenges of underfunded projects.

The “Right” People

Quantity and quality are not synonyms in the project management world. While selecting the right human resources for a project does not necessarily mean getting the most “expensive” personnel, acquiring those people with appropriate skills and relevant expertise does take concerted effort. It means taking time to carefully review resumes, to conduct meaningful interviews, and to ponder the potential effectiveness of the mix of people on the project team. Of course, the “right” people are typically in great demand to participate on multiple teams. Therefore, a project manager may need to rearrange activities and/or dependencies so that the appropriate people can participate. Typically, a few “good” people can outperform a large number of lesser talented resources in a shorter time period. Rescheduling is well worth the effort when it results in fewer personnel costs as well as a shorter time to implementation.

“Time is Money”

In an attempt to keep costs at a minimum project managers are often given completion dates that are unrealistic. Organizations believe that an aggressive timeframe keeps everyone motivated and does not allow for the cost overruns often associated with lengthy projects. Competitive pressures may also drive a tight time schedule. After all, being “second to market” is not a goal for most companies. In the face of this focus on time project managers need to assess what really needs to be accomplished on a project. This assessment needs to be made before developing the project schedule so that any tasks that are not essential to complete the core requirements can be eliminated. Too often project managers attempt to complete “everything” that is requested. In this futile effort the project may actually not accomplish anything concrete. In such situations the project either has to obtain more money in order to complete anything or has to be severely downsized or even scrapped. Any of the preceding three situations means that money has been wasted. It is better to complete a basic deliverable than to deliver only promises.

“We Can Fix It Later”

Every project includes some interim deliverables prior to the final deliverable that do not turn out as planned. The tendency is to say, “We can fix it later”. However, “later” seldom comes, and so the inadequate interim deliverables do not meet expectations. If an interim deliverable is part of a larger downstream deliverable, there can be a cascading failure effect. (Remember the Challenger’s “O” rings?) Even if the interim deliverable stands alone, its implemented version may not be used or worse yet, may result in a “work around”. The potential for interim deliverable failure needs to be a part of proactive contingency planning with scheduled backup tasks and resources to address those deliverables that truly need fixing now not later.

In summary, there are creative methods to stretch budget dollars effectively. While the tendency is to focus directly on costs, the concepts discussed in the above article represent some other types of actions that can be effective when project budgets are anything but realistic.

Susan Peterson, M.B.A., PMP, is a consultant who manages diverse programs and projects in both the private and public sectors for individual organizations and consortia. She also conducts enterprise assessments of project portfolio management practices. Prior to establishing her consulting practice Susan led major efforts for Fortune 100 organizations throughout the United States. She teaches the Project Management Simulation capstone course in the University of California, San Diego, Project Management certificate program and is a member of the curriculum advisory committee. She can be contacted at

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Handling Project Re-work

A reader at asked:  How do I account for project re-work in the project plan? 

In anticipation of us all doing the right thing, there really isn’t any formal guideline for handling re-work in a schedule which is universal.  Every organization sets their own norms.  In fact, I’m not sure I would want to call it out as a separately tracked item unless there was an ongoing issue with re-work from a project team, which does happen.  The expectation for any properly managed project is that some tasks will come in early and some will be late for a variety of reasons, including re-work.  The end result is that you hit the mark at the end of the project, or at least come close (within 10-20%).  Perhaps the better question is: How do I keep all my projects on track?

I have used a few different methods myself in the past:

  1. After the project schedule is complete, add a portion of your contingency time to all tasks resulting in deliverables.  If re-work isn’t significant or required to be tracked separately, this is ideal and you just track the schedule and actual time spent in the plan without doing anything special.  In general, as time on the project progresses, some tasks will come in early and some will be late (for many different reasons including re-work).  In some environments (e.g. software/technology) there will be other documents such as bug tickets from which you can derive the project time on re-work if necessary. Track in a separate spreadsheet if necessary.
  2. Possibly in conjunction with #1, and if re-work tracking isn’t important, just track the rework as actual time against the original task or the QA task for the deliverable being re-worked.  Without the contingency, your performance against baseline will not be good, but you will have accurately captured the project timeline status.
  3. If re-work tracking is important to the project and your organization, add new tasks and deliverables to the project without re-baselining.  These too will be deviations from the baseline.  If the deviations become too significant, then you may want to consider re-baselining the project which will mean re-estimating all tasks going forward.

The bottom line is that estimates are exactly that — estimates.  We don’t need to tell people “no rework allowed”.  At the same time, we need to maintain the expectation that everyone is doing the right thing and trying their best to minimize re-work.  Well managed projects tend to “hit their mark” because some tasks are early and some are late.  If you are not experiencing this, there may be some issues with your estimating process or scheduling process, and you need to reflect on how to best manage that.  If this is allowed to go on for too long, you will tend to build dysfunction into the project team and the organization.  The PMBOK® Guide tells us that the result of poor quality and a lot of re-work is a demoralized and low performing team.

Another possibility for frequently missed projects is that expectation setting may need adjustment.  I’ve always set the expectation, especially on software and knowledge projects, that if you are going to be late (for any reason) that you will “go the extra mile” and put in a little overtime to bring the project back on track.  I don’t put this out up front — if someone is repeatedly missing the mark I will ask they meet this expecation in the future.  Over time, this usually helps improve the estimates and inputs into plans — after all, who wants to work nights and weekends all the time?  This is a gentle and fair way of encouraging the team to perform.

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Scope Verification of Software Projects

A reader over at PM Hut asks, “How [can I] calculate delivery compliance in an engineering/ Software(IT) project?”

From a Project Management viewpoint, I had some difficulty in understanding the term “delivery compliance”, so I’ve taken the liberty of thinking of this as scope verification — how we determine that what was delivered meets the project requirements. There is then a second part to this inquiry — how is it measured?

This can be a complex question or issue. We all know from the 70s and the work of Gerald Weinberg (The Psychology of Computer Programming) that testing software does not prove the absence of bugs. Where scope statements require high reliability then, the measurement becomes uncertain. Complex and large projects also create challenges for verification and measurement.

I believe I can put some simple structure around this complex question. During the early years of my software and software project management career, I worked with engineering/software development teams at GE Information Services that were challenged to:

– develop systems that worked with high reliability – 99.999%
– meet the demand that memory and cpu utilization vary no more than 1% from release to release (since clients were billed on this basis)
– provide high client satisfaction — an “A” average was required on client report cards

This was “RASM” (Reliability, Availability, Scalability, Maintainability) before the acronym was coined! Here’s how this was achieved:

Verification required a robust process to maintain the chain of accountability for the requirements. This process included:

– written SMART requirements (specific, measurable, achievable, realistic, time bound)
– diligent requirements reviews (indirectly more of Weinberg’s work)
– diligent design reviews
– coding standards
– peer reviews of all code
– management sign off on all changes
– developer created unit test cases which contributed to future regression tests
– test cases which went through a similar process to the software development process.

Testing was also a critical part of the process. In my opinion, testing these days has become too reliant on use cases. Use cases make fine exemplars or clarifications of requirements, but are poor test cases — users rarely do what’s expected of them 100% of the time. Testing needs to be a good mix of black box, white box, and glass box testing to ensure you are capturing as many issues as possible. The requirements need to become your checklist. Further, in addition to looking at the checklist an item at a time, you need to step back and make sure they meet the big picture (here’s a nice role for use cases, as well as additional testing to verify the interaction of component).

Critical components of testing in the environment included:

– a strong, multi- and cross-platform configuration management system to manage builds and their versions
– ability to easily integrate developer unit tests into other test beds through defined test frameworks
– automated testing to drive high test coverage in shorter periods of time
– a measurable regression test bed (ensure no unexpected changes in CPU/memory or functionality)
– load testing (how many simultaneous users could use the system with no database or other system deadlocks)
– stress testing (what happened when the expected limits of any system aspect were exceeded).


Now that we’ve had a look at the intended delivery outcomes and the process to achieve them, let’s take a look at the key metrics which were in place and how they were used to assure delivery:

1) Regular reporting of number of open tickets and issues by priority, software system, client, and age
2) Regular reporting on system and application availability. Goal was 99.999% (scheduled down time was considered meeting goal, unscheduled was not)
3) Regular client survey results, requiring a specific average (usually something like A- or better). Clients were proactively called on a regular basis by client services to gather the information.

To further reinforce the compliance of delivery, these three metrics were generally tied to financial compensation and overall employee performance reviews. Everyone in the organization carried a responsibility to help meet the metrics. (Note: See my earlier article Time, Deliverables, or Outcomes? for more on the perspective of the triangular relationship of quality, availability, and high client satisfaction.)

It is also interesting to note that we found client satisfaction directly linked to number of open tickets. It wasn’t enough to just close the high priority issues. Initially there was an attempt to ignore lower level issues. As the number of these issues grew, client satisfaction dropped. Once out of compliance, we initiated a period in which only low level tickets were addressed. Client satisfaction increased within two quarters and we then adopted a more balanced approach than just closing high priority, high impact tickets.

After these key metrics, there were other regular reports available including:

– measurement of time on projects
– measurement of time on issues and other non-project work
– measurements of system and application usage on display monitors throughout all facilities, including metrics such as up time, availability time, number of simultaneous users, transaction rates, etc.


Delivery compliance is a complex topic. Its not about a simple metric or measurement. I’ve attempted to put together a picture of a framework for a development process which drives an organization toward effective, high quality delivery. The process was supported by three key, simple metrics which kept everyone aligned to the highest priorities and values of the company. Additional metrics helped build team work and rally employees around milestones (e.g. the day we reached 10,000 simultaneous users on our private telecommunications network and mainframe processors).

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

The Power of Checklists and Sign Offs

I usually have to visit a copy shop at least 2-3 times a year to fulfill various needs for PMI meetings and events. This past weekend I had a critical business need to have a small number of copies made and spiral bound for a customer meeting. With FedEx Kinko’s being the closest, I dashed off last night to have the copies done. Since I don’t frequently visit, this was like a “first visit” all over again.

Fully expecting to pick up my copies on Sunday, I explained what I needed. In under 5 minutes, Kevin, a customer consultant had a copy made and bound for me to review and approve. I was quite surprised when he informed me I could come back in a half hour and pick them up. Being on the way out to dinner anyway, I returned in under an hour to pick up the finished product.

Packed with my copies, I found two similar checklists which read something like this (I’ve shortened, but maintained the key messages):

– I took your order, repeated your instructions, and offered you enhancements.
– My order was repeated back to me and I am confident my instructions were clearly understood.
– I have reviewed the sample and approve the order.
– I produced the order according to the instructions.
– I quality checked all previous work and finished your order according to your instructions.
– I quality checked the final order using quality standards and the instructions. To the best of my knowledge, this order meets your expectations.

Both lists were cross checked and initialed by Kevin and another employee. My order was very small compared to many (8 spiral bound copies of a 20-25 page document). But the process was followed and the checklist completed. The work was high quality, and my simple document looked impressive. Based on the timestamps, this order was completed by Kevin and another associate in 5-10 minutes.

The important message here is what went through my mind as I left:

– The shop employees are efficient and accurate. They did a great job at setting my expectations.
– They followed the process for even a small order.
– My order looked great and care was taken to make sure my needs and expectations were met.
– This obviously wasn’t a bureaucratic process and the checklist captured the key points — the order was quickly produced and waiting for me on my return trip after dinner.
I can trust they will complete larger future orders with high quality.

There is an important message here for projects large and small. Having checklists make sure the best practice and process is followed. By initialing each box, I’m assured those completing the work felt good enough to put their name on it. They didn’t make me sign or initial the form, but I was more than willing and gave my verbal consent while in the store. But most important, I walked away feeling the project team was able to take on larger challenges while still meeting my needs and expectations.

Do your project sponsors have the same feeling when your projects are completed? Will the next project charter name you as the Project Manager?

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Past Articles

Links and Buttons

Add to Technorati Favorites

Blogging Fusion Blog Directory

San Diego Blog News

Submit Express Inc.Submit Express - SEO Services


All opinions on this blog are those of the site owner and do not reflect the opinion of any other entity. Information on this site may contain errors or inaccuracies; The Project Notebook does not make warranty as to the correctness or reliability of the site's content. If you believe something on this site is inappropriate and should be removed, please contact the site owner at sdcapmp at aol dot com.


"PMP" is a registered mark of the Project Management Institute.


© 2010-2012 Ray W. Frohnhoefer, MBA, PMP, CCP