Kimberly Wiefling is the blog leader for the University of California – Santa Cruz which I write for from time to time. She’s about as witty as they come. Check out this hilarious video and then buy her new book, Scrappy Project Management.

Hello everyone! I’m sorry it has been so long since my last post. I have been going through a job change, and the last month has been hectic with getting things shored up at my previous company and (trying) to get up to speed at the new company. I recently listened to my favorite podcast, The PM Podcast, and episode 75 is about project monitoring.

I really enjoyed this episode. Upkeep during project execution and finding problems as early as possible has always been an important topic for me. I think that is why I found interest early in the Critical Chain methodology, because it offers great ways to highlight and pinpoint problems early on. In particular, I felt the soft skills addressed in the discussion were very important. After all, you can have mountains of data, but if you don’t know how to present it well or what to do with it, it has no value. My key interests are being able to take quantitative data from something like EVM and combine it with qualitative data in order to target specific work packages, resources, or stakeholders who are having/causing issues.

I will let you listen to the podcast, but it was wonderful. Also check out the accompanying power point presentation here.

Fear encourages short-term thinking. One of Deming’s classic stories was about a foreman who didn’t stop production to repair a worn-out piece of equipment, because he feared that stopping production would mean missing his daily quota. Instead, he let production continue. When the machine failed, it forced the line to shut down for 4 days.

The manifestations of fear are many:

* Fear of reprisal
* Fear of failure
* Fear of the unknown
* Fear of relinquishing control
* Fear of change
* And more….

Some management philosophies assert that a certain level of fear is healthy. I disagree, and feel along with Deming that fear is so unproductive and harmful that it should be driven out as much as possible.

If a project manager is controlled by fear, it is likely they will withhold negative information or delay it because of a fear of reprisal. Of course, the best scenario would be for problems to be understood and addressed as soon as possible. EVM reporting and other types of status reporting can easily by manipulated by crafty project managers who are fearful.

Project managers who have a fear of failure because of the environment they are working in will never try anything new. How can progress be made unless you try something new, and take some educated risks? It can’t.

Fear of the unknown can paralyze project managers, sponsors, and stakeholders alike. A big part of project management is supposed to be about dealing with uncertainty, and making the unknowns known. Good project management in itself can alleviate much fear associated with unknowns.

Ah yes, relinquishing control. This is a big one. I know project managers who feel they must micro-manage their projects because if they don’t, thing will never get done correctly. They might be afraid of failure, but more than likely they are just control freaks. In order to properly lead and achieve the best results, a project manager must be able to give guidance and direction, then get out of the way. A good indicator that a project manager may have this fear is when you hear them purposefully talking PM jargon and trying to make themselves look smart and sophisticated in meetings with the customer. This attempt at razzle-dazzle is inevitably a symptom of the “it’s all about me” syndrome.

Fear of change is a big one. Change management is probably the most difficult thing I’ve had to deal with on my projects. People are resistant to change by nature, unless they are the ones initiating it. For that reason, I’ve found it is always best to make the WIIFM (what’s in it for me) painfully obvious, and involve experts from the stakeholders as much as possible when working the project. The more people you can involve that are at the lowest end-user level, the better. Do not just include the managers of these people in your project….that is a sure fire way to ensure the end-users are fearful of the change when it comes.

A quality organization understands the value of the people who work in it. The same goes for project management. Training project managers, analysts, and everyone else who regularly works on projects in the company methodology, soft skills, etc. can bring significant rewards.

Many companies use the cop-out of “on the job training” to sidestep any responsibility to have a formal system in place to ensure their people are constantly learning how to do their jobs better. I am not saying that OJT isn’t valuable, but it can’t be the only training “effort” put forth by the powers that be.

The companies I have experience with that get this have the following resources and programs in place:

• A project resource center with books, periodicals, and other materials
• Time specifically scheduled for training and learning each month
• Presenters, either from the team or externally, giving a talk monthly to the whole group
• A significant amount of funds in the budget earmarked for training
• Sending a few people each year to seminars and events like the PMI Global Congress, etc. –And then those people present what they learned to the whole group when they get back
• A formal mentor program whereby new employees are paired with a vetran
• Company methodology and process training

There are many other ways to show commitment to project management training and education, these are just a few. Please leave your ideas and experience about best practices as a comment below.

The textbook wording of this point varies, but is usually something like “Stop making decisions purely on the basis of cost.” When I read the various descriptions however, I believe the textbook title is not an adequate summary.

When Deming talks about not making decisions purely on the basis of cost, he is referring to a plant perspective and talks about the importance of having regular suppliers. This fosters long-term relationships leading to loyalty and mutual improvement. The key factor is that when you look at the big picture, it is usually not cheaper to switch vendors all the time based on price, because you are going to pay for it in other ways in the long term.

In projects, I see two specific applications of this point. First, be sure to consider costs and benefits of a project in terms of the entire system, not just the project alone, or even the specific department or customer who pays for it. Second, weigh the costs and benefits on a project for the complete expected lifetime of the final deliverables, not just the duration of the project that creates them.

The Entire System

To be truly effective, projects must be in alignment with the entire system in which they are carried out. I have personally witnessed many projects which were undertaken with a very narrow focus, and as a result caused unforeseen problems for either the supplier or customer of the final product. When these dependencies are not taken into consideration, rework and band-aid fixes are usually required later on. Many times, these efforts incur significant costs and do not result in an optimal situation for everyone involved.

Additionally, lack of broad consideration can incur more total cost for the organization, even when the department who sponsored a project saved money. For example, Department A sponsors a project in which the ROI seems obvious when considered locally. Department B is dependent on Department A however, and as a result of this change, must incur new costs to accommodate the new state. Had Department A been willing to incur some additional cost, it is possible Department B would not have incurred any, or very little. With the common cost center silo mentality within organizations, it is very common for functional managers to “not care” about what it costs other departments. After all, they aren’t responsible for other department’s budgets, only their own. This is a great example of one of the benefits of a truly independent portfolio and project management team. Projects can then be carried out in light of what is best for the entire organization as a whole.

The Total Lifetime

How many opportunities arise during a project for the short-sighted project manager to cut corners to meet their project constraints? More subtly, how many opportunities to enhance the quality of the long-term result are overlooked because of a short-term focus?

You can plan a project in such a way that the actual production of the deliverable will be cheap, but maintenance will be expensive and frustrating. The same project can be run so that it takes months longer and costs more up front, but the maintenance cost and effort is drastically diminished. Which option makes the project manager look better in a short-term environment? Which option are project managers encouraged to lean towards? Now, which one probably has a higher ROI for the entire organization when you factor in the total lifetime?

As an idealistic beginner in the world of project management, I am continuously frustrated by the ignored opportunities that arise in almost every project. Many times project managers focus on minimizing scope, and the Standish CHAOS report even supports this measure as a factor in project success. These missed opportunities are hard to quantify however, and I believe the Standish report misses them too.

During the course of project execution, it is common to find opportunities to enhance quality. In my experience (when I am not the project manager), the only way these get worked into a change request is for the customer or sponsor to take the ball and run with it. Usually though, the project team usually comes up with the best ideas for enhancing the project. The sad truth is that many project managers, overtly or implicitly, discourage these ideas from their teams if they will result in an increase in scope, take them off schedule, or over budget. It may be that sponsors are reluctant to sign off on more time or money for a change that was not initiated by their team. It may be that the project manager has enough to do without trying to advocate an increase in their workload. Either way, ideas for improvement are suppressed.

These issues result from short-term and/or localized thinking. I believe Dr. Deming would say to think big, and think long-term.

Deming’s third point urges practitioners to design quality into processes, using inspection as an information-gathering tool to do so. In project management, the processes and systems make up a methodology. Does your organization have a consistent methodology, or does everyone run projects their own way? Inspecting project performance through the lens of continuous improvement facilitates applying lessons learned to a consistent and ever-improving methodology. This can not be done effectively unless there is a consistent system of managing projects in the first place.

Because projects are inherently unique, the specifics of how they are managed may require modification on an individual basis. If a consistent methodology is used as the basis however, deviations can be reviewed and further enhance the methodology by documenting best practices for specific categories of projects. The “deviations” can be developed into subject-specific best practices within the common framework. Furthermore, various components of the methodology should be a guideline, whereas critical planning processes should be standardized as much as possible to facilitate the formation of sound theories and best practices. For example, the methods of estimation should be consistent, while some aspects of management style should be left up to individual project managers.

Too often, inspection on projects is used as (or believed to be) a method of blaming project managers when their projects are behind, or applauding them when the projects are ahead of schedule. They should be neither. A performance report indicating a significant discrepancy in the planned time, cost, or quality should be viewed as an opportunity to go back to the planning process and figure out why it was so inaccurate. If the project manager followed the planning processes outlined in the methodology, this is new information with which to enhance those planning processes. If the issue appears to be execution, find out if the project manager is abiding by the guidelines set forth in the methodology, or if they are ignoring them. Compliance can be a people problem, but Deming would argue that over 90% of the problems in any situation can be traced back to flaws in the system, not the people.

When appraising the performance of project managers who work within a consistent methodology, performance to plan should not be such a large factor. Instead, the (1) ongoing contributions to improving the methodology and (2) compliance and success of execution should be considered. Not using the methodology can lead to poor performance, but it is better to measure the cause, instead of the result. To me, this is a key distinction in the Management by Objectives philosophy of people management versus Deming’s view on how performance should be evaluated. Think on the incentives in the MBO versus Deming management philosophies.

In MBO, a project manager may be enticed to add so many schedules and cost padding that they are always the hero when they come in under budget and ahead of schedule. They can negotiate out many beneficial features and other quality elements of the final product, and then if they add a few back in because of all the extra time and money, they win again. This factors into why many projects only meet most of the customer needs, not all of them. In my opinion, this is what makes project sponsors slash schedules and budgets….they know what is going on. The project managers add even more fluff because they know it will be cut down, and the vicious cycle continues. Where is the incentive for continuous improvement? The focus is clearly misdirected.

If one were to apply Deming’s philosophy to project management, much of the struggle from above is avoided. The focus shifts to creating and continually improving a consistent system from which project managers plan and execute projects. The addition of arbitrary amounts of fluff time and cost by project managers is not possible if there is a specific, universal method for making estimates. Contingency reserve is still there, but in a consistent manner based on what makes sense for the organization.

Project managers are encouraged to embrace and improve the methodology. Rewards and recognition result from actions that truly enhance the entire organization’s ability to provide quality to the customer. Regular reviews of lessons learned and other input from project managers can be used to enhance the methodology, one small step at a time. Statistical measures across multiple projects such as standard deviation from plan and EVM metrics can provide useful insights into opportunities for improvement.

Performance excellence does not happen overnight, and it does not happen to an organization as the result of a few great individuals acting in silos. Performance excellence occurs over years of embracing a consistent set of systems and processes that everyone seeks to continually improve.
Project management is about dealing with uncertainty. The point is to eliminate as much of it as possible through careful planning, and deal with the inevitable unknown-unknowns appropriately. Deming’s third point when applied to project management eliminates much of the uncertainty in projects by using an invariant framework which can be continually improved.

Dr. W. Edwards Deming was recently re-introduced to me in my Project Performance and Quality Assurance class. I have heard of him before and touched on some of his philosophy in other classes, but focused much more in-depth this time. The majority of his philosophy around quality and organizational management resonate with me. So, I’ve decided to do a series of articles on Deming’s 14 points, and how they relate specifically to the field of project management. I may decide to not touch on all of them or I may. I am not really sure at this point.

The goal of the 14 points: To help everyone enjoy their work, and produce excellence.

References and Resources

Managing for Quality and Performance Excellence
Deming and Goldratt
Out of the Crisis
The Deming Management Method
The New Economics
Four Days with Dr. Deming
Deming Route to Quality and Productivity
Deming The Way We Knew Him

Today I listened to one of my favorite podcasts, The Project Management Podcast. Cornelius did a great job of putting it all out on the table as far as earning PDU’s are concerned. Check out the episode here.

I wanted to have a great new article ready for today’s post, but I am applying for scholarships through PMI and so had to put some effort into the required essays.

So, today will be a lazy post on my part. Here is an interesting video I found that Bas put out back in 2004. Much of this is in the spirit of his book which I am reading now. Check it out!

Interesting camera work Bas!

Have you ever let someone down even though you had tried your best and thought you were doing what they wanted? Few things are frustrating as putting forth tons of effort only to find out you were working on the wrong things.

Expectations are such an essential and common component of human relationships and communication that most of the time they are taken for granted. Taken for granted is exactly what expectations should not be.

In project management, we have a plethora of tools and techniques to help us understand expectations and meet them. We understand and fulfill those expectations through good requirements management.

Every stakeholder in a project has expectations for it, including the sponsor, team, customers, and even upper management in many cases. These expectations need to go through a review process and possibly become requirements, which in turn may lead to derived requirements that arise solely to support the main requirements. So what should come out of this review process? What makes a good requirement for a project?

I put together my own acronym based on the old standard SMART goal setting components, combined with sources on soliciting great requirements (see citations at the end of this article). I hope you like these items although I have to warn you, they ARE SORTA NUTS.

What factors do you look for in great requirements?

Sources and links:
The Art of Requirements Gathering, George Spafford
Eliciting Software Requirements, Presentation by Jesse Borschel – Sioux Empire PMI Chapter