It’s said there are no new project management sins, just old ones repeated. It’s also said that we don’t learn the lessons from past projects and this must be true, otherwise why would we keep making the same old mistakes?

My apologies, everyone, for going so long between posts. I’m not blog-fading though. I think finals in conjunction with all the parental duties during the holiday season really had be bogged down.

This week, I’m the guest blogger for the University of California Extension, Santa Cruz and their “The Art of Project Management” blog. I will be doing a “Best of PM Network 2007″ series, as a year in review for the publication with my commentary on each topic area. You can check “The Art of Project Management” at http://www.svprojectmanagement.net.

Some of the blogs are going to be extensions of posts I’ve made here throughout the year, and some will be new.

Happy New Year everyone! I hope to have many new blogs coming your way soon.

I finally got a chance to read this month’s PM Network magazine. There is an article on keeping project team motivated that caught my attention starting on page 38, written by Simon Kent.

The article reminded me of a previous post I wrote back in February, 2007 titled Motivational Theory in Project Management where I laid out some of my thoughts on the topic, specifically in relation to Frederick Hertzberg’s work.

The PM Network article is mostly in line with Hertzberg. Instead of focusing on theory or concepts, the article mostly cites specific examples of how various project managers motivate their teams and keep them that way. I enjoyed the experiential approach to the topic.

Jonathan Bowman cited monetary rewards, and he’s right in saying that you have to be careful how that is done. Team-wide bonuses for early completion or coming in under budget are good ways of doing this. Hertzberg cites monetary compensation as a hygiene factor, not a motivator, and I am inclined to agree with him. Money can be used as a force for recognition however, if directly linked to accomplishments. Personally, I would stay away from giving individual bonuses based directly on project performance. This could provide incentives for people to excel or look good at the expense of someone else and/or the project objectives. Instead, accomplishment should be documented in the performance review process and have their relevant impacts on salary increases.

Here are some of the techniques brought out in the article that I especially agree with:

• Create a team area for co-located projects. Do some banners and sit people who are on the project next to each other whenever possible. This fosters communication and can help create a better team atmosphere.
• Create a learning experience. This one I really enjoyed. It speaks to leveraging strengths of your team members, while assigning them a supporting role in some other area they are interested in learning more about. This way, they can learn without creating undue risk and stress that would come from just assigning them responsibility for something they unexperienced with.
• Use a monthly ‘team barometer’ to gauge how things are going on the project. Joli Mallick, PMP offered this up, and I think it’s a fabulous idea. It’s such a good idea, I’d like to throw out some of my thoughts on how to implement it:
  • Exactly 3 targeted questions, no more, no less.
  • Completed monthly via a website or survey tool of some kind.
  • Anonymous
  • No multiple choice. All free-text.
  • The questions are generated by the head project manager, with input from subordinate project managers and leads.
  • The questions change throughout the project. Using the same questions over and over is boring and irrelevant. A team member gets the sense their feedback is actually being used if the questions are original each month. This shouldn’t be a tracking tool to measure communication performance or something. It’s a direct feedback mechanism for actively managing projects day-to-day.
  • Use a monthly status meeting to review the results and discuss the problems and solutions.

Something like the above would take a few hours each month to administer, analyze, and communicate. It would be worth it though. This is like a Delphi method session each month to highlight the biggest problems and concerns on the project as early as possible. The time spent should not be difficult to justify.

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.

Deming’s first point is an important one. There needs to be commitment from the top to make continuous improvement a priority. To do it right, most firms would probably implement a Project Management Office from which continuous improvement activities can be based, one that has dominion over methodology and training at a minimum. The PMO should implement systems to ensure best practices and lessons learned are gathered and implemented. Sharing them will not be enough; they must actively be incorporated into the methodology.

Fully embracing this point should also include a strategic basis within the PMO, or even a separate portfolio project management group. Don J. Wessels, PMP does a great job of laying out the vision of a truly strategic focus on projects in the 2007 ISSIG Review, Volume XI No. 1. The article is titled “The Strategic Role of Project Management” and is a wonderfully insightful read. In this work, he references the PMI’s Standard for Portfolio Management by saying, “While project management and program management have traditionally focused on “doing work right,” portfolio management is concerned with “doing the right work.” It is like allocative efficiency versus productive efficiency in economics. As I read this article and thought about the concepts more and more, I realized it is very true that much of project management today is very tactical and without strategic basis. Embracing Deming’s first point requires viewing continuous improvement from the perspective of the whole system.

In a large company like the one that I work for, various groups have their own versions of a PMO. While this may not be optimal, it does allow for groups with a specific subject area focus to tailor their approaches. This is fine, as long as the group or individual overseeing projects has made a long-term commitment to continuous improvement, and they are committed to ensuring projects are in alignment with organizational goals. So often, the alignment comes at a departmental level at best, and can actually be detrimental when looking at the whole organization. A long-term thought process is required. The leader of the project group must have the ability to not let fire fighting overpower the improvement strategy.

Finding the right balance of documentation and methodology can be challenging on small projects. Here are some tips.

I have been managing small projects for some time now. Some of my project are really tiny, I’m talking about 8 hours of work max. Others can be 2 week or month-long projects. Some span several months, and then you get up into the 6 month and year plus undertakings.

As a student of project management, I have often struggled with finding the right level of planning and documentation for these various sizes of projects. Some things are obvious, as in I’m not going to go through a formal project plan and communication plan, etc. for an 8 hour project.

As a rough guideline, here is what I use:

Level 1 (Projects longer than 6 months in duration)

-Full blown project planning and documentation for whatever is appropriate to the project

Level 2 (Projects 1-6 months in duration)

-Simplified project planning document, which includes brief communications and risk plans, along with scope definition, limitations, objectives, and deliverables. Also containts a simple WBS and Gantt-style task list with dependencies, owners, estimates, and a timeline.

-Weekly status reports to stakeholders

-Project meeting agenda/minutes template – I use this to document the agenda before meetings about the project, then update it immediately after the meetings and send it out to all the stakeholders. It includes a section for decisions regarding agenda items, and a seperate section for action items.

-Project Closure report at the end which summarizes the business benefits gained and effort spent. This is a good post-mortem look at ROI. Lessons learned are also attached to this.

Level 3 (Projects 1 to 4 weeks in duration)

-Simple project request form, where the requestor fills out their definition of requirements and business justification. Since these requests are fairly simple, I normally work out the details of the requirements over the phone with the customer, and just make updates in my project documentation log (which I keep for all projects big and small)

-Weekly status reports to all stakeholders (sometimes yes, sometimes no – depends on the project)

-Project Closure Report

Level 4 (Less than 1 week)

-For this I still have the simple project request form

-Email when the deliverable (usually 1) is ready for validation, asking for approval

I keep detailed activity logs for all levels of projects, even if it’s a 2 hour job. My department has a sharepoint site set up that works really slick for this.

I find that using these guidelines, and the templates I’ve developed, really makes it easy for me to keep my ducks in a row and keep my stakeholders informed about what is going on, for any small to medium project I am managing. For more information, check out this great article by Simon Buehring which I found today and very closely matches my style for managing small projects.

This article was originally published at http://projectmanagementlearningcenter.com/.

In the April 2007 edition of PM Network, there is an article titled “Master Plan: IT executives need to develop an eye for project managers” that I would like to comment on.

The article is mostly based off a study done by Gartner Inc., in Stamford CT, USA. One sad but true statistic stated that 20-30% of IT executives “have a ‘dismissive attitude’ toward project management”. Those are the same execs that suffer “from poor quality, late delivery and unrealistic project costs.” I can related to this information from my personal experience, and would venture a guess that when you move into executives in operational areas, the dismissive attitude towards proper project management increases. The majority of IT execs seem to have seen the light and made the realization that there really is value to be delivered by well run projects by individuals who have the right skills to do so in a formal manner.

If I had to guess at a percentage, I would say that more like 40-50% of operational executives have a dismissive attitude towards formal project management, although the number seems to be decreasing. There are still a majority of director and above level people who seem to not perceive value in formal project management. I see the trend towards realizing project management adds value as positive reinforcement for my decision to enter the discipline.

But I digress. Back to the article in PM Network, I found a few points insightful and worth sharing here. First, the report by Gartner classifies IT project managers in 4 categories:

1. Novice – Some project experience, lacks formal training
2. Apprentice – Some project experience, shows initiative towards managing projects, has sought out and attained some formal training, ready to manage a low-risk project.
3. Journeyman – 2 years of project management experience or more, formal training in scope and risk management, advanced scheduling and best practices.
4. Master – 5+ years successfully managing projects, usually PMP or other certification attained.

Only 15-20% of project managers are in the Master group. I would place myself either in the high Apprentice or just barely Journeyman category. I’ve had a good amount of formal training and several years of managing projects, albeit projects managed without knowledge of the discipline of project management.

I feel the categories above are a bit tenuous, as I have met project managers who by the definition above would fit into the Master category, but do not display what I would refer to as Mastery skills in managing projects. The last box in the article goes into five characteristics of masters that I feel are much more accurate:

1. Diplomacy – ability to manage the business relationships effectively
2. Strategic Vision – ability to see the big picture and eliminate “silo paradigms”
3. Policy Responsibility – seek process improvements and question existing policy constraints
4. Collaboration – cross-functional leadership skills
5. Risk Management – advanced risk management goes beyond a risk management plan checklist

I would like to add a few to this list:

1. Effective Planning – see my previous post on Alpha Project Managers and how they spend twice as much time planning as non-alphas.
2. Superior Communication – Again a reference to Alpha PM’s – This goes with diplomacy and collaboration, but everyone knows the successful project management comes mostly from excellent communication.
3. Decisiveness – the ability to make tough decisions quickly and stick to your guns
4. Conciseness – the ability to drop pretenses and execute. Many junior project managers I know seem to throw around a lot of jargon in meetings to try and wow those not educated in the discipline. Masters I have worked with drop the unnecessary, speak on the client’s level, and get to the point.

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

Human Resource Skills for the Project Manager: The Human Aspects of Project Management, Volume 2

This book by Vijay K. Verma provides a good overview of various project aspects regarding relationships, communication, and human capital in general. I personally found it helpful in the descriptions of various theories out there, and a good starting point to branch out and seek more specific research and information.

The book is split up into 6 main sections: Communication, Motivation, Conflict, Negotiation, Stress, and Leadership. Some of the areas of interest for me I took further and branched out on, and you may recognize some of the topics from posts I have been writing.

Specifically, the communication, motivation, and negotiation chapters prompted me to take further action in seeking out academic and industry research and thoughts on these topics.

This made a great textbook for my HR Project Management class this semester. I recommend it to anyone who wants to be able to better understand these areas within project management as a good place to start on the journey to self-improvement. It may help highlight some counterproductive practices you are engaging in and do not even realize.

It is set up much like you would expect a text book to be however, soft cover and short novel dimensions notwithstanding. It is not something I would classify as an easy or casual read. (It’s not quite as dry as the PMBOK guide though!)

Today I received an email from Timothy Johnson over at Carpe Factum. I met Timothy when he did a presentation for the Sioux Empire chapter of PMI here in Sioux Falls, SD. His presentation was titled “What your project team isn’t telling you.” I wrote about the presentation back in January.

I found out that Timothy’s new book, Gust: The “Tale” Wind of Office Politics is available for pre-order! I placed an order today for both of his books. I haven’t read either yet, but based on meeting Timothy and hearing/reading his content in the past, I’m sure they will be good. He’s a smart guy with good thoughts to share, so check out Carpe Factum and Timothy’s books.

Congratulations Timothy on the debut of your new book! Stay tuned for a review of both books after I’ve received and read them.