The Project Notebook

Smaller is Better and More Effective

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

It seems as if everything comes in larger and larger sizes — including projects. While a giant pizza or a super-sized drink may be refreshing, a large and complex project often seems overwhelming to all participants as well as to the project manager. This article focuses on “small” approaches to major projects.

The presence of many unknowns is one of the most challenging aspects of projects. Regardless of the sources of the unknowns — technical specifications, scientific barriers, market demand, etc. — the project manager is the one who must provide the direction and the methods to convert unknowns into knowns. This responsibility does not mean that the project manager must be the one who conducts the research necessary to solve the mysteries. Rather, the project manager must assess the strengths of the team not only in terms of specific expertise but also in terms of problem identification and solution skills. All the knowledge in the world is useless if it is applied to a symptom instead of a problem. Determining when “enough” information has been assembled is also a critical assessment. Therefore, using a few people who can identify relevant problems and quickly resolve them is more effective than having an entire team running in multiple, counterproductive directions.

Another challenge occurs when a lengthy timeframe is estimated for project completion. Virtually every project of this nature needs to use a phased approach rather than attempting to schedule all of the activities at the beginning of the project. For example, a project to develop a new drug may span many years before the drug is finally brought to market. While a project manager may be tempted to fully populate a Gantt chart with thousands of activities that culminate in product release, a more effective approach is to “plan only what you know”. This technique means that accurate time estimates can be made only for the initial phase of research. The high-level project plan should definitely have milestones and deliverables defined for the full length of the project. However, there is no point in detailed planning beyond the first phase until there are indications of success. Even then, the detailed planning should only extend to the next phase. This practice forces an organization to identify upfront the criteria for success for each phase as well as to require that projects continue to “prove themselves”.

Most large projects require large project teams. In these situations individual participants may feel that their contributions are not necessary or valued. Large project teams provide lots of opportunities for people to “hide” or even “disappear”. Meanwhile, the project manager gets hounded as to why there is not a high volume of work forthcoming from such a large number of team members. Running “lean and mean” (using a small project team) is one method to ensure that each team member has high visibility and accountability. This method is not always practical given the amount of work that may be required to complete a project. In those cases that mandate a large number of participants, a more appropriate technique is to organize the total large project team into smaller teams within the project. Each team has a leader who can be chosen by the project manager or by the team. This method may require a different approach to project planning through specifying more tangible deliverables. However, it also keeps individuals focused on near-term accomplishments with defined responsibilities. Those who choose to “hide” or to attempt to “disappear” are quickly identified before their lack of participation negatively impacts project outcomes. At that point project management mentoring, coaching, and/or disciplining can be initiated in a timely manner.

The main emphasis behind all of the techniques and practices that have been described in this article is that even “super-sized” projects need not be overwhelming for project managers. Whether it’s building an aircraft carrier, chairing a fundraiser, or cleaning the garage, “smaller is better and more effective” when it comes to project management.

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 committee. She can be contacted at

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

I Just Want Everyone to be Happy!

By:  Susan Peterson, M.B.A., PMP

Copyright 2011, Susan Peterson, All Rights Reserved

 There are many books, CDs, Internet blogs, and videos as well as numerous seminars that claim that any situation can be framed as “win-win” for all participants.  With so much emphasis on “happiness for all”, project managers are often pressured to sustain euphoria among everyone who is involved with a given project.  It may seen at times that the success of the project is measured by the percentage of “smiley faces” among the project participants.  However, project managers know that there are often unpopular decisions that must be made for the overall good of the project.  While no project manager lasts long if everyone is always unhappy, there are times when s/he may have to make some people temporarily unhappy.

I am leading a “damage control” project for a client organization that has a great deal of public contact.  A former employee consciously ignored a policy that had been developed with much balanced input for the benefit of the organization’s customers.  This individual claimed that customers were happy that the policy was not being followed.  In reality, this individual did not want to deal with any conflict nor take the time to work with customers to explain the policy’s benefits.  I was brought into the organization to lead the project because virtually all of the customers are unhappy, including the vast majority who understand the policy, support it and wonder why flagrant exceptions were made.

An example of a common project management situation that may make some people unhappy occurs when agreement must be reached on a realistic project schedule.  “Drop dead” dates for project completion are often set by individuals who have little or no responsibility in achieving a successful implementation.  It falls to the project manager to investigate what actually needs to be accomplished, to determine what is driving the completion date, and to negotiate an equitable resolution.  In carrying out these activities, the project manager may be subject to ridicule, threats, and angry exchanges.  However, if the project is completed on time because the final schedule is actually realistic, it’s amazing how people forget how “unhappy” they were with the project manager at the beginning of the planning process.

Similarly, some project managers feel that they keep everyone happy when they accept any and all changes that are proposed during the course of a project.  I’ve witnessed some project managers who develop a standard response, such as “We can finish your request in about two weeks”.  This type of response is made with the hope that the requestor will forget the request or that the world will end before the “two weeks” have past.  However, what typically happens is that the project flounders in a sea of “two-week” change requests.  The project manager who only wanted to “make everyone happy” by being agreeable then discovers that not only is everyone unhappy – but that they all expect their requests to be fulfilled.

I leave you with this little twist on a well known saying:  “You can make all of the people happy some of the time.  You can make some of the people happy all of the time.  But you cannot make all of the people happy all of the time (unless you have unlimited access to mood-altering substances).”

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 as well as the Project Portfolio Management course in the University of California, San Diego, Project Management certificate program and is a member of the curriculum committee.  She can be contacted at

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 

If Only We Had Known

By: Susan Peterson, MBA PMP
Copyright 2008, Susan Peterson, All Rights Reserved

There are at least three separate groups of analysts who are assessing the current global economic situation.
• One group is convinced that they “saw this coming a long time ago.”
• The second group admits to being “blindsided.”
• The third group includes those who may have seen something dire coming but didn’t think that there would be a monumental catastrophe.
Project managers know that they must always be in the first group in order to make adequate contingency plans, to mitigate problems, or to avoid catastrophes completely. This month’s column is the first in a series that will focus on indicators that can alert project managers to take preventive actions or to make contingency plans in order to avert disasters.

“Who needs goals?”
Some people think that project goals are actually defined by the final deliverable or target milestone. If the project purpose is to install a new software package, some project stakeholders will perceive that the project goal is successful software implementation. However, the goal of the project is its target accomplishment. In this example as in many others, the project goals need to be determined before the final deliverable (solution) is defined. If the organization actually wants to improve its processes (a potential project goal), there may be many final deliverables other than software implementation that would be better solutions. Specifying a solution in advance of or in place of project goal definition and agreement often leads to projects that are declared failures. Project managers must emphasize the necessity of determining goals in order to provide focus and direction for the project. Specifying the solution without identifying the problem to be addressed is akin to providing an answer without first asking a question. The process involved in goal setting also serves to involve stakeholders from the beginning and to resolve any areas of significant disagreement early in the project activities.

“We don’t know where we’re going, but we have to get there quickly.”
Planning is another classic project activity that can be perceived as a waste of time. “We used to plan, but no one followed the plan” or “How can we plan what we don’t know?” are common reasons given to justify the avoidance of project plan development. While there may have been past bad experiences with planning, no project proceeds smoothly unless there is an effective plan that is followed. Involving all stakeholders in the planning process can be effective in overcoming resistance to planning. This involvement builds an appreciation among stakeholders of the types of activities and related human resources that will be necessary to accomplish the project goals. It can also aid understanding across diverse stakeholders of the responsibilities of the entire team.

“It’s not wise to take only what you’re given.”
Even in the best of times project managers may find themselves in intense competition with each other for money, human resources, and capital assets that are often in scarce supply in organizations. In the interest of the enterprise perspective rather than a single project, it’s not expedient to declare a “winner take all” contest to identify the one project that receives the most and the best of everything. However, project managers need to work with each other throughout their projects to determine what is needed, when it is needed, and what degree of flexibility is appropriate.

Using this practice can result in a more coordinated allocation across current and future projects. It promotes cooperation that results in more effective execution of all projects and reduces or eliminates the time-consuming competition that can occur among projects. The practice can also uncover that the organization is attempting to accomplish too many concurrent projects and that it needs to defer or re-plan one or more efforts.

Project managers know that they have to remain alert and responsive to indicators of potential problems.

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. An overview of her program and project specialties is available at; select “Resources” then “Consultants”. 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 committee. She can be contacted at

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