When Project Managers Attack!

As a project manager I have had my share of frustrations over the course of my career. Some days while working on certain projects I feel like why bother. I get to the point of thinking, if others don't care about the project's objectives, why should I? I can only give one good reason why the project manager should care about their projects; THAT IS WHAT WE GET PAID TO DO!

Certainly there are other reasons to care: a sense of ownership, responsibility to our customers, a commitment to finish what we started, personal pride, professional integrity, because it is the right thing to do, because others are counting on us, because as leaders we must always do what is expected, etc, etc, etc...

Project managers wear many hats. We are members of teams, leaders of teams, we are followers, we are stakeholders, we are fiscal planners, we are risk managers, risk takers, planners, schedulers, mentors, quality assurance reps, writers, motivators, listeners, we are empathetic, we are sympathetic, we demonstrate common sense when others don't, we demonstrate a fair and balanced approach to problems, and lots more.... You get the idea. You can see why we are sometimes frustrated. You can see why we need to be as professional as we can all the time.

I have communicated with many people that read this blog, and there is a lot of frustration out there in the Project Management world. The consensus seems to be that yes, there are organizations that do a good job of Project Management and have a great support structure for their project managers. But, it seems that a large majority of organizations don't do a very good job implementing and/or supporting project management, and according to what I hear, quite a few do a terrible job.

In many organizations the project manager position (if one exists) isn't viewed as a profession, but a job that can be performed by virtually anyone in the organization. That can be frustrating for those of us that consider ourselves to be professionals. We all get frustrated sometimes no matter what job we have. We all feel like we aren’t being supported which can lead us to believe that we are being “setup to fail”.

You know what, we all get paid to do a job, and sometimes the job isn't easy, fun, or structured the way we would like. If our managers value us as individuals then they should be willing to hear our ideas about what we need to be successful.

Keep in mind; the project manager can’t be successful on his or her own. They need a management structure in place that is committed to seeing Project Management succeed. Management must at least agree that Project Management adds or can add Value. Management must be able to state the Value that Project Management is adding or should be adding to the organization. If management can’t do that then you probably need to find a new place to work. It is that important.

As you probably know by reading this blog I usually try to reinforce the basics of Project Management, and today won't be any different.

Rule #1 - Team Conflict hurts Projects!

Team members need to remember that they must manage their departmental responsibilities as well as their project tasks to support the project to which they are assigned. Their management needs to assist the team members in setting priorities so that the project work doesn't suffer when the departmental work becomes more important.

Rule 2 - Management Apathy Hurts Projects!

All levels of impacted management must remember that if they are not engaged and interested in a project's success then their lack of support is a major contributor to project failure.

Rule #3 - Poor Planning Hurts Projects!

Project Management can only work when the project manager is given time to plan properly. Also, the project sponsor must explain the project's objectives clearly, and most importantly, obtain the entire team's commitment to meet the all of the project's objectives (this is a critical planning component). Simple project management principle: If you Fail to Plan, then you Plan to Fail. The failure to allow enough time for proper project planning is the sponsor's fault.

Keep fighting the Good Fight!

Loose Lips Sink Ships!

Have you ever heard of the "Three Ships to Success"? The one that is considered the best to have and/or demonstrate is Kinship. Kinship requires that you take time to nurture and build your relationships to make them stronger. The second ship is Sponsorship. This requires that a senior person in your organization take a personal interest in your career and your success. The third ship is Showmanship. This ship is your ability to delight and amaze your superiors, peers, and subordinates with your abilities and talents. While the three ships are important, without ability, skill, and knowledge the three ships will not take you very far.

While you work on your "three ships", keep in mind that if you work in a highly political environment you need to work on the following:

Don't criticize others.
Use data to back up your claims and don't exaggerate your needs or your customer's requirements.
Try to understand the political process where you work no matter how hard that may be.
Understand that many rules are out of date, no longer make sense, are not enforced, and are often ignored. Use this to your advantage, but never at the expense of another person, group, or your organization's reputation.
Prove yourself through your efforts, not by talking about what you once did.
Be respectful of others. Keep in mind they determine if you are treating them with respect, not you.
Be reasonable (this can be difficult). Note - I'm not sure who determines reasonableness.

On a personal note, I have never liked or performed up to my highest potential in highly political environments. The things I have listed above are weaknesses of mine and are things I need to work on to be a better project manager.

Remember relationships based on personal preference and personal styles are often major contributors to highly political organizations. Lastly, keep in mind the perceived and demonstrated values of your organization will drive the politics.

Rule of the day, the Three Ships of Success can help you to overcome political hurdles.

Project Management - Don't Do These Things

Don’t believe everything you are told about a potential project’s benefits. Investigate for yourself and plan accordingly.

Don’t take on a project that doesn’t have a strong sponsor that is committed to seeing the project succeed.

Don't forget that most project assumptions should also be risks.

Don't set project expectations that are higher than reality can deliver.

Don't try to define reality too early in the project planning phase.

Don’t define solutions that do not address needs.

Don’t forget to manage customer expectations.

Don’t forget to thank your team members for the good job they are doing.

Don’t be a whiner. A leader never whines and a whiner never leads.

Don’t forget that leaders need to have credibility.

Don’t forget that credibility requires honesty, dedication, commitment, and capability.

Don’t forget that people are the number one reason for project failure.

Don’t forget that empowering teams is a management function.

Don’t allow others to influence your attitude. Be positive in the face of adversity.

Don’t forget to have fun while working on your projects.

Don’t forget that Project Management is mostly art and some science.

Four Project Principles - Don't believe the Hype!

As I was reminded recently, it is always good to go back to the basics of what you know when confronted with issues that seem overwhelming.

Here are four basic Project Principles and some of my ideas regarding what to watch out for when managing your projects. As always, I welcome your feedback.

E-mail me at sfseay@yahoo.com

(1) Projects are often constrained from the start (Initiation Phase) by a fixed, finite budget and defined timeline. In other words, many projects have budgets that have strictly defined constraints and a timeline with a set start and end date. This is obvious to all project managers, however what is not so obvious is many times these budget and timelines are not sufficient (or realistic) to accomplish the project’s objectives. From the start, ensure the project sponsor is aware that budget and timelines may need to be renegotiated as project planning progresses.

(2) Projects can have many complex and interrelated activities that need to be coordinated so that proper organizational resources can be applied at the proper time. The big thing to watch out for here is "proper organizational resources". While you may not have input on which resources you get for your project, you do have input on the project’s estimates and schedule. Do not allow others to dictate unrealistic schedules or estimates for resources that are unproven, unreliable or untested.

(3) Projects are directed toward the attainment of a clearly defined objective(s) and once they are achieved, the project is over. Yea, right! Not all projects have clearly defined objectives, and if they do, they are not always achievable given the budget, time, and organizational constraints. Not only that, your organization’s culture can be a huge impediment to successfully managing your project. Be very careful when accepting a new project to ensure you are not being setup to fail. Do not accept projects with unclear or unrealistic objectives.

(4) Projects are unique. Because they are unique, the risks are great and failure is always an option. Minimize the risks by informing your sponsor that until you are finished with your initial project planning activities you may not be able to provide realistic budget and time estimates. Once you have completed your initial project planning activities, (project planning is continuous) provide your sponsor with an estimated budget and time range, and remind him or her that as planning progresses these ranges will be adjusted to closer reflect reality.

Strategic Planning and Other Myths

Are your completed projects adding value to the organization? Was an ROI calculated for the project during or prior to Project Initiation? Did the project benefits ever come to fruition?

Virtually all projects - unless mandated by law or born out of technical or business necessity - should either reduce costs or increase efficiency. One way to ensure the organization will be working on the right projects at the right time is to involve the executives up front in aligning, prioritizing, and ranking proposed projects, and then ensuring they link to the Strategic Plan. If the proposed projects do not align to your organizations strategic goals then they should not be undertaken.

If your organization is good at Strategic Planning, you can avoid many of the traps that plague most organizations.

Poor Strategic Planning Traits:

There is no formal document that links the organization's projects to the organization’s strategic goals and plan.

Senior Management is not engaged in strategic planning, which leads to complaining later about how long it takes to get projects completed and frustration over why certain projects were cancelled or not started.

Projects are started without enough resources or have poorly qualified resources assigned to them.

Many projects that are completed do not achieve any improvements and actually end up costing the organization more money than if they had not undertaken the project.

Project priorities continually change, and resources are always in flux or in conflict with competing organizational needs

Project Managers have low morale and are pessimistic about achieving their project objectives

Executives have set measures that relate to their silos, which can conflict with what is best for the organization

Business plans ignore systems that are broken or in need or repair/replacement

Poor strategic planning almost always leads to undertaking wasteful projects. Even a good strategic plan will not be successful if the organization does not have the right people, tools, and data in place to support the organization's goals.

Project Management Websites

Today's posting includes some hyperlinks to a few Project Management websites. I use these sites on occasion and they all have something of value for the Project Manager. On a side note, some of the sites are government related, technology related, or process oriented.

In many cases you may need to do a search on "Project Management" to find what you are looking for.

---------------------------------------------------

Minnesota Office of Technology

PM Boulevard

GanttHead

TenStep Project Management Process

American Society for the Advancement of Project Management

Florida State Technology Office

Tech Republic

Software Program Manager's Network

Good, Short Article on Project Failure

Click here for a good article on Project Failure. I would also add that your Project Management Processes, if poorly designed, can be a contributing factor in project failure.

Stupid Things Project Managers (and others) Say!

Quality Planning is only concerned about the number of bugs/problems in the final product.

The delivery date is going to slip because we have learned about new requirements.

Projects are always late and over budget. We shouldn't worry.

We can't predict our final costs because the requirements are changing.

The estimate is in line with management expectations.

Our schedule is good because we used a project-scheduling tool.

We can always add people to meet the deadline.

We are behind schedule because the customer can't make up their minds.

We can cut our testing time to make the delivery date.

Good people make up for bad processes.

Our process is good because it is repeatable.

If they quit we can quickly hire someone to take their place.

We don't involve the people doing the work in estimating because that will increase costs. Besides, they will just inflate/pad their estimates.

Using a Tool is not a Risk.

The sooner we begin coding the more successful we will be.

We will save more by reusing code, not architecture.

We will worry about the cost of maintenance later. There is no time now.

If it doesn't work we will fix it when we have time.

We don't need to document because we put comments in our code.

Technical people don't like to write documentation and we shouldn't insist that they do. Besides, they are terrible writers.

You can't blame the Project Manager. How were they supposed to know?

All of the problems we have been having our 's fault.

Trust me; we will deliver everything you want on time and at or under budget.

I think you get the idea. As Project Managers, we were hired to tell the truth and include the good, the bad, and the ugly in our status reports. Sugar coating project issues and problems for management will only get us in trouble later. Don't make excuses. Use status reports, e-mail, voice mail, and most importantly face-to-face meetings to relay project status. Don't be afraid to deliver bad news. Just make sure when you present management with issues and problems with your project you have a plan to get it back on track.

Be Responsible, take Ownership, and most importantly, be Trustworthy.

Constructive Behavior

Many of us deal with difficult people using the age-old adage of an "eye for an eye". If we are snubbed, we ignore the other person. If we are disrespected, we in turn show disrespect. If someone cheats us, we cheat them. This mentality is not only self-destructive, but is damaging to the career of a project manager.

When we reciprocate with bad behavior against another, nothing is resolved. By reverting to negative behavior we have fallen into a lose/lose relationship where nobody wins, and we do as much damage to ourselves as we perceive we do to others. What can we do when we feel bombarded by the negative attacks? There are several things we can do to avoid the trap of reciprocating rudeness with rudeness.

I suggest that you read a couple of books I have found to be enlightening. The first is Stephen Covey's "Seven Habits of Highly Effective People" and the other is "Love is the Killer App" by Tim Sanders. Both books offer powerful insight into the human condition and more importantly offer critical advice you can use everyday in all of your relationships.

Some things to be aware of when dealing with others:

Be aware of the Perceptions others hold about you

Keep a balance between your Emotions and your Actions

Seek first to Understand, then be Understood (Stephen Covey Habit)

Be an Active Listener

Diagnose before prescribing

Consult with others you trust before making important decisions

Be Trustworthy

Don't Coerce, but Persuade

Accept the fact that some people will just be Unreasonable

Be the Solution, not the Problem

The best times in life and the worst times are usually tied to our relationships. Do not be a victim of your relationships, but an example of how others should act.

More random thoughts

The last several months have been challenging for me as a project manager. In fact, if I think about it my entire career in project management has been a challenge. Some days are better than others, but as I look back over the last eighteen years I'm glad I chose the profession of project management.

Over the course of my career I have met many people that call themselves project managers, but when questioned about their processes, they don't have much to say. Without a repeatable project management process in place, I'm not sure what you are doing, but it isn't project management.

You will find as I have that many people are promoted to have the title of project manager because of their organizational, business, or communication skills. Others are promoted because they are a highly valued employee and with good technical skills, but their personality isn't geared towards managing people. For project managers to be successful, keep in mind what I have repeated in the past - focus on process, communications and results in everything you do. Any person that is well skilled in these three areas will be successful in what ever endeavor they seek.

As PMI says, project management is both a science and an art. We must continually improve our skills (Sharpen the Saw) and always be aware of our communications. Dealing effectively with challenges and adversity will ultimately define who we are as project managers (god or bad). More times that not you will be judged and assessed on your personality, not your performance. Keep that thought in mind when dealing with your peers, your manager, and your customers.

Skills, Reputation, and Performance

As with any profession, your career prospects improve with ever increasing skills. Project Managers must have the skills to do the job, but also must have success in managing projects. One key to success in any field is to set goals. Ensure that your manager has bought into your goals and will use them as a basis of your performance review.

We must be ever mindful that our reputation affects our careers. A good reputation is earned and takes years of effort. You must be known first as trustworthy, an effective team leader, a person that works well with others, and for your resourcefulness. A project manager's job is unique because not only do we have to be great communicators, but we must also manage to the triple constraints. In addition, we must instill confidence with those we work with, and let them know that our project’s objectives are attainable, relevant, and important to the success of the organization.

When you take on a new project people’s perceptions will be based upon your performance, your results, and your communications. This falls in line with my view which says that all employees (including those at the top) should be measured (equally) on the Processes they use, the Results they achieve, and their Communications. What good are results when you have violated many or all of your department's/organization’s processes or have communicated poorly, which caused descent and ill will among your peers? Results are always important, but not at the expense of Process and Communications.

Remember, you don't need a high profile to succeed. You can achieve more with a very low, but exceptionally successful profile. You will know you are on the right track when management comes to you with the really hard work that needs to be done quickly, but efficiently without sacrificing you or your manager's integrity.

Don't take it Personally

Many people have fallen into a bad habit of taking things too personally because they want to protect the smaller picture (self) instead of the big picture (other people, relationships, the situation, and sometimes the truth). How do we get through the times where having a positive attitude seems impossible? Well, we can always choose to act as if the positive feelings/attitudes are still there. It is that simple, and it is always our choice.

We choose all of our feelings and actions. No one else is at fault for what we think, what we feel, and how we act. As Project Managers we can't let others dictate how we feel about ourselves. Project Managers by nature need to have thick skin and can't let the opinions of a few dictate how we feel and act.

It isn't a radical idea to believe that we can choose how to behave, regardless of how we feel. Additionally, by changing our behavior we might just discover that behaving differently can change how we feel. This changing of behavior knocks aside the notion that feelings help us find truth, especially when we are trying to assess an important business or life situation.

I feel that the old saying "Perception is Reality" is destructive. Many people act solely on what they perceive. Perception is only Perception. We can argue about what Reality is, or is not, but basing Reality on what we perceive can really screw up Reality for us and everybody else.

Mental Note for Slow Learners: Sometimes it seems like you can't change anything. Sometimes by changing yourself you change everything.

To the Idiot Mobile!

Here we go on another project journey. You have met with your stakeholders and all of them are in agreement as to where the project is going (objectives), what the journey will look like to get to the project’s destination (plan), and what can be expected when the project is complete (deliverables). But wait, your project (like a journey in a car) has been taken over by somebody else and is now out of your control. You have just found yourself in the back seat (no longer driving and in control) of the Project Idiot Mobile. You discover quickly that it is careening out of control and you are on a white-knuckle ride to who knows where. What do you do?

I have taken a ride in the Idiot Mobile more than once and here are some tips you can use to avoid this mind-numbing ride.

Be the Leader of the Team From the Start. Control the keys of the Idiot Mobile and don’t let anyone drive it and make sure you always leave it in the garage. Don’t assume anything unless it is documented in your project charter’s assumptions section. Don't allow stakeholders to take over your project and direct it onto a path that wasn't agreed upon in the Project Charter.

Understand Politics is a Way of Life on Your Project. Understand you will have to deal with people who don't want you to succeed. As Tom Peters said be aware that your project can fail because of "...people that are envious, people who feel their turf is being invaded, people who have a b-i-g stake in the status quo, people who are just plain afraid of change. Therefore, you will need ... Herculian (Clintonian) political skills to ... nuetralize ... finesse...and in some cases just plain outsmart-surround-coopt ... these naysayers".

Have Thick Skin. Be smart up front and try to recognize who will be unsupportive of your efforts. Be prepared with a response. Be able to accept criticism and bounce back quickly. Know when you are on the wrong path and get on the right path quickly.

Make Strong Allies with Those that Have the Power. Remember that those with the power make the decisions. A good project manager is a good politician, and also keep in mind that Politics is The Art of Getting Things Done.

Project Ethics

An ethical Project Manager is a successful Project Manager. The PMI has established a Professional Code of Ethics that all Project Management Professionals (PMP) must adhere to. These ethics are meant to ensure that all PMPs abide by a set of values, and they live up to those values in pursuit of their careers.

Project Ethics won't ensure you are a successful project manager, however not behaving ethically will almost always ensure your project will fail. As stated in the PMI Code of conduct, which in my opinion is the most important ethical behavior, a project manager must accept responsibility for his or her actions. This means admitting to all your stakeholders when you are wrong, learning from your mistakes, and putting actions into place that will help you to avoid making the same mistake twice.

A project manager is responsible for all activities that occur or fail to occur on their project. It is unethical for a project manager to blame others for mistakes that were clearly the fault of the project manager.

Do you have the ethics to accept and take responsibility for your mistakes? Are you willing to do this in the face of your harshest critics? If not, you need to leave the project management profession because you aren’t a mature, responsible professional, and as such you are hurting the profession of Project Management.

2005 Resolutions

2004 is almost over and it is time to make some Project Management resolutions/goals for the New Year. In looking back over the past year I can see where I have made some mistakes, and I see these mistakes as learning opportunities. Now is the time to resolve to make changes in how I manage my projects.

My 2005 resolutions are:

Be a better listener

Apply the principles of Earned Value to more of my projects

Begin each project with the end (deliverables) in mind

Rely less on e-mail and more on face-to-face conversations

Be a better Project Leader

Accept the fact that criticism from others is part of the project life cycle

Be willing to accept failures and use them as learning experiences

Believe that most people on your project team are doing the best they can do

Be positive, enthusiastic, and supportive of others

ProjectSteps

ProjectSteps has been updated with a bright white font so the site is more readable. I have vacation this week so I will be busy working around the house and enjoying the Christmas holiday.

Have a very Merry Christmas

Can you hear me?

Do you manage your projects mostly from your desk? Are you falling into the trap of managing projects via e-mail, voice mail, fax, letter, and failing to communicate with your customers and stakeholders face-to-face?

People value one-on-one conversations. A project manager that doesn't spend significant time on his or her project speaking directly to their customers will not be as effective as the one the takes the time to conduct meetings in person.

As project managers we are selling "experiences" and "solutions". Can you effectively sell your ideas as a faceless e-mail machine? Can you "WOW" your customers with tired voice mails and bland status reports?

Good customers want to see you as much as possible. They want to feel your enthusiasm, experience your excitement, and have you tell them eye-to-eye that "it’s all good".

Don’t cower (and sour) behind your keyboard sending status reports and e-mails and think your are doing your job. You can't gain your customer's trust unless you speak with them one on one.

As Tom Peter says, "If there is nothing special about your work...you won't get noticed, and that means you won't get paid much either".

It is hard to get noticed when people can't see you. BE VISIBLE!

What I Believe - Part II

When it comes to Project Management, "what I believe" is that we all must follow Stephen Covey's advice and continually "Sharpen the Saw". After reviewing the new version of PMI's "Guide to the PMBOK", I must say it is much more readable and logical. I spent some time recently sharpening the saw by reviewing the new PMBOK, and while it isn't a book you would want to curl up with on a cold winter's night, it is the foundational reference for Project Manager's everywhere and we all need to be familiar with its content and terminology.

The last few weeks have been challenging for me as a Project Manager. Uncooperative team members, hidden agendas, and scope change requests have been running amuck on my projects. Through it all I have relied on proven Project Management processes, techniques, and tools to help me through the rough spots and get my projects back on track.

As I develop an internal training course – Introduction to Project Management - I'm reminded that we all need to remember the basics of Project Management.


Do you have a signed-off Project Charter?
Do you have a Project Sponsor that is actively involved with your project?
Do you have a cohesive, high performing Project Team? How do you know?
Do you have a written Project Plan (word document)?
Do you have written, agreed upon Requirements?
Do you have a Cost and Schedule Baseline?
Do you have a Communication Plan?
Do you have an Implementation Plan?

Don't forget the "basics". Project Failure is often linked to neglecting one of the above items.

What I Believe

Tom Peters is an inspiration to me. He brings so much passion to his beliefs and states them in a way like no one else. After reading his "This I Believe! - Tom's 60 TIBs" I became inspired to start a series entitled "What I Believe". I certainly don't have Tom's passion, nor do I have his brain power or writing abilities, but I do know "What I Believe" and I will attempt to pass some of those beliefs here (as I have in the past).

In the Project Management world What I Believe is the average project team member has a very low level of what I call "project success maturity". My experience has shown that many of the people I have worked with - or that have been assigned to my project - are only interested in themselves or their "silo" of responsibility. I have to say this is one of my greatest frustrations as a project manager. After saying that I also realize that this is my problem to solve.

When managing projects, I understand that I have to be the focal point of the energy, emotion, and passion that drives the project forward (and hopefully inspires those around me to see the bigger picture). If there are people on the team that don't want to play, and I and the other team members have made a concerted effort to get them on board to support the project, then they need to find somewhere else to play. I have no problem telling them that and helping to facilitate the process of having them removed from the team.

As Tom Peters says "... all quests worth undertaking - a Girl Scout merit badge or a Nobel Prize require audacity and willpower." To paraphrase Tom, we need to continually challenge conventional wisdom, accept the lumps, and persist until vicotry.

What I Believe? Be a great leader, be passionate about what you are doing, and always challenge assumptions.

Don't allow unmotivated, emotionally unintelligent people to change your course or dictate new rules.

Can I get an AMEN?

Break it Down

When faced with large projects the first thing I try to do is to break the project down into smaller, manageable chunks of work. Many of our projects can be large and complex. Breaking the project down into management tasks will help to:

Simplify the process of creating Metrics to manage project progress

Reduce Risk by creating shorter timelines with less overall scope

Make it easier for individuals and groups to understand the Work they must perform

Make Planning easier and more realistic

When creating your Project Charter be sure to address all phases of the project, but emphasize that the project will be delivered in phases. In addition, make sure your Project Charter clearly addresses the:

Project Objectives

Project Benefits

Project Risks (initial assessment)

Project Constraints

Project Assumptions

Project Dependencies

Resource Requirements

Project Cost and Duration estimates (establish your range for this estimate and state it)

What the Project won't address or deliver

There are other items that can be included in the Project Charter, but addressing the above items clearly and getting the sponsor's buy-in will be critical to getting your project off to a good start.

For more information regarding a Project Charter click here

Reforming Project Management Theory and Practice

Reforming Project Management Theory and Practice. Hal has created a very good project management website that provides great insight and valuable information that any project manager can use.

In a recent posting Hal talks about leadership and mentioned that as project managers we should provide just enough leadership to support the efforts of others. While on the face of it that statement sounds reasonable I believe that you may not know how much "just enough" is.

My thought is a project manager should provide leadership consistently throughout the project with all stakeholders versus trying to figure out how much is just enough. Obviously when we are working with executives and senior management we need to keep our messages and leadership short and to the point.

As Hal says "what we need on projects is to cultivate leadership throughout the team" and I would add we need to always Lead by Example.

Change and the Project Manager

Every project we work on as Project Managers brings change to the organization. Those individuals or groups that react negatively to change usually do so out of fear. How can we overcome this fear early in the project so it doesn't manifest itself later and throw the project into chaos?

To help in the process of managing change lets look at the "Stages of Negative Reaction to Change". As stated in the book "Project Manager's Portable Handbook - Second Edition" (David I. Cleland and Lewis R. Ireland), the stages of negative reaction to change are:

* Disruption of Work

* Denial of Change

* Realization of Change

* Negotiating Change

* Accepting Change

Basically the authors are telling us that Change needs to be managed, and furthermore managing change is a process. Inflicting change on an organization without realizing the repercussions or backlash can contribute to project failure.

Project Management can provide structure and help articulate the reasons for a change. The processes behind Project Management are there to help move the organization to accept the changes that come about as a result of the project's deliverables.

Keep the following in mind to help manage the change that will occur as a result of your project:

* Use SMART Objectives in your project (Specific, Measurable, Attainable, Relevant, Time Bound)

* Create a Risk Management Plan

* Create a Project Schedule that is realistic and agreed upon

* Create an atmosphere of Trust

* Define and Use a Scope Change Process

* Solicit feedback throughout your project from the stakeholders that will be experiencing the brunt of the change

Change will be disruptive and can cause unexpected behavior and results. Understanding the positive and negative results of change prior to its implementation will help you to head off problems early. Be patient with your stakeholders, and if necessary be ready and willing to escalate issues to senior management to get quick resolution and closure. Allowing stakeholders to hold your project hostage because of their biases and fears will only lead to project failure and ill will.

Understand the positive and negative effects of the change you are implementing, develop goals early in the project to mitigate the negative effects of the change, communicate your plan to all stakeholders, and involve your stakeholders in developing and effecting the change.

Setting Up a Project Management Office

When developing a Project Management Office keep in mind the following items:

PMO Need - Why are you setting up a PMO? What are the Pros and Cons?

Cultural Change - What barriers will there be to setting up PMO? How will the PMO overcome these barriers?

Organizational Assessment - What is the Project Management Maturity of your project managers and the organization?

Methodologies - What Methodoligies will you use in the PMO? Templates? Business Processes?

Resources - How many people will comprise the PMO staff and what are their roles and responsibilities?

Training - What type of training does the staff require? What type of training does the organization require to support the PMO?

Metrics - What type of metrics will the PMO be responsible for collecting?

Lines of Authority - Who runs the PMO and why?

PMO Type - What type of PMO are you going to setup? Strategic? Business Unit Focus? Project Control Office?

Executive Buy-In - How are you going to get your company executives to buy-in to and then support the PMO?

Setting up a PMO is a daunting challenge that all to often ends up in failure. If your organization is seriously considering starting up a PMO make sure they have done their homework.

There are several excellent books that will help you and your company setup and operate a successfull PMO.

Take a look at:

The Strategic Project Office - A Guide to Improving Organizational Performance - J. Kent Crawford

Advanced Project Portfolio Management and the PMO - Multiplying ROI at Warp Speed - Gerald I Kendall, PMP and Steven C. Rollins, PMP

One final thought, don't be afraid to bring in an outside consulting company to help you through the process of setting up your PMO. Most PMOs are shutdown within the first few years due to the lack of perceived value by senior executives.

Are you Trustworthy?

As I get ready to develop an internal training course entitled "Introduction to Project Management" I'm reminded of my past Project Management training. Invariably all Project Management training courses talk about the triple constraints, baselines, critical paths, scope, risk, cost management etc. While all these things, and more, are important to manage on every project, I think a lot of my training has been lacking in “What Matters Most” when it comes to successfully managing projects.

In my career I have found that the ability to work well with others, show empathy towards their needs, and being trustworthy have done more for my successes than being overly reliant on tools such as pert charts, resource loaded histograms, and quantitative risk analysis discussions. Granted, I haven't managed very large (over $10M) or overly complex projects, but I don’t think that matters when it boils down to what is important when managing projects. When managing any size project the project manager needs to focus on what is most important to that project. Only you, your sponsor, and stakeholders can answer that question. Is the most important thing getting the project done on time, coming in at or under budget, delivering at a high level of quality, or having a big WOW factor? (See Tom Peter's – “The Project 50” book for more on the WOW factor). You must decide what the Project “Driver” is before you begin your planning.

Don't get caught in the trap of believing that if you meet your Time, Cost, and Scope objectives your project is a success. If your users and/or sponsor aren't satisfied with the project's results YOUR PROJECT IS A FAILURE!

Every project needs a project sponsor, charter, a budget, a realistic agreed upon schedule, competent resources, a list of valid assumptions, a list of the project’s constraints, dependencies, and people assigned to your team that are dedicated and personally committed to seeing the project succeed. However, you as the project manager must have the trust of all stakeholders and demonstrate that your are committed to doing your best and delivering on your promises.

To get back to my initial point, your internal Project Management training (you don't just rely on external vendors do you?) must put a heavy emphasis on Project Communications and teaching your audience how to be TRUSTWORTHY Project Managers. Without the trust of your peers, management, and customers your project management career won't last very long.

PMI 2004 World Congress

I'm in Anaheim, California this week for the Project Management Institute's (PMI) Annual World Congress. This year's event has been well organized, and I have gained a lot of new knowledge that I can use on my projects. Stay tuned for more information.

The Keynote Speaker for this years event was Tim Sanders. Tim authored the book "Love is the Killer App" and gave a great keynote presentation. I have purchased his book (you can also by clicking the link on this page) and when I finish reading it I will write my thoughts here. Suffice it to say that Tim left a big impression on me and I'm sure all the other attendees that listened to his presentation. Tim is a smart man that has some great insights that all project managers can use when working with members of their team. Check out his website by clicking here.

I will provide new links, hints, and tips in the coming weeks that I acquired while attending this years conference. Check back in the next few days.

Communications and Listening

How well do you listen? When speaking with others, most people want to make a point and fail to remember that communicating is always two-way. When we are e-mailing, talking on the phone, or creating presentations we must remember that there is a communications feedback loop. That feedback loop helps to ensure the communication was received and understood. If people misunderstand your message, you failed to communicate.

What do you do when you realize that you aren't being understood? You listen carefully! Listening attentively lets the communicator know you are supportive and paying attention. When involved in a conversation, don't interrupt; let the speaker know you are listening by using reinforcing body language and verbal cues.

When planning your communications, use the words of Stephen Covey, "Seek first to understand, and then be understood".

Project Failure

If you are an "experienced" project manager and haven't had a few project failures, in my mind, you aren't a very good project manager. Project managers must constantly push their team members towards exceeding their comfort levels, take (calculated) risks, be decisive, make firm commitments, and be aggressive when base-lining and managing the triple constraints (Time, Cost, Quality). Just like a successful NASCAR driver, a project manager must learn to live close to the edge of disaster, but while doing so, he or she must aggressively manage their project’s Risks.

In my opinion, too many project managers are unwilling to set firm expectations with their team for fear of being unpopular. There are going to be times when your project team doesn't really care if a milestone is missed or a promise isn't kept. The problem is your project isn't always your team’s top concern. Don’t forget that. You live with and for your project and at the same time some of your team members might loathe your project. Many team members have other responsibilities outside of your project and your project may be preventing them from doing their regular job.

Project Tip - If you find that you have members on your project team that aren't 100% committed to achieving the goals of your project, you need to start thinking about replacing them.

Based upon my experience, - at least on IT projects - most project problems that are encountered in the Project Execution phases are the fault of the project manager. Proper Risk Management will help the project manager foresee and mitigate many problems that will arise during project execution. If you have lots of problems and issues on your project you did a poor job of Risk Management in the planning phase.


Some things to keep in mind to avoid failure when planning your project:

Be crystal clear when communicating with your team. All important communications should be in writing.

Don't allow project committees or executive oversight groups to dictate how you plan your project.

Communicate quickly to your team and senior management if you believe that your project is out of control.

Don't assume that suppliers or vendors will be honest with you. Make sure you continually follow-up and get commitments in writing (preferably in the contract).

Split your project into manageable phases.

Ensure that your end users are involved every step of the way.

Communicate Status as often as is needed. Include bad news, problems, issues, and concerns in your status report and be sure to include how you plan to overcome them.

Don't let your project fail because you aren't communicating or your team isn't functioning properly.

Believe in the statement that “Project failure is always the Project Manager's fault”!

Surround Them, Margnalize Them, Forget Them!

Tom Peters a highly regarded speaker and writer said it best in his book The Project 50, “as project managers we should not try to convert our project enemies by overcoming their objections” and I would add through appeasement. Tom states “we should set out to surround and marginalize them; additionally, the most effective change agents ignore the barbs and darts, their time is spent on allies and likely allies”.

It seems to be in our nature to take on those that oppose us, particularly if they have been attacking us behind our backs. This taking on of the opposition is a waste of valuable project time and detracts the project manager from the task at hand. All projects will have detractors, whiners, and complainers. Don’t waste your time trying to convince them of the error of their ways. Let your project’s results answer your critics!

As project managers we need to spend our time working with our advocates and supporters, not answering our critics. If you say you don’t have critics on your project than I say you probably aren’t a very good project manager. The project manager that has friends everywhere on his projects is usually trying to satisfy everyone, and many times at the end of their project – if it ever ends – there will be low overall satisfaction due to all of the tradeoffs that were made between all of the competing interests.

When you push people, demand excellence, set deadlines, push for quality, hold individuals accountable, and are firm on agreed upon commitments you are going to ruffle some feathers. Get over it, and realize no matter what you do on your project there will always be detractors. Just don’t let the detractors sway you from implementing your project on time, on budget, within requirements, and most importantly with a satisfied customer as your biggest fan.

People are the Problem?

The employees within your company either help it to prosper or impede its effectiveness. Because employees at all levels of the organization make decisions that could effect your project, we as project managers need to be aware if these workers are motivated, properly placed, supported by senior management, and well trained.

A good question to ponder before starting work on that new project is: will your project team be staffed with the right people, having the right set of skills, doing the right things, at the right time, in the right place?

Also, are your project team members motivated and committed to doing a good job, and are they supportive of the company's goals, mission, and values? Do they have the support of their management? Is there a senior management representative assigned to your project that will act as Project Sponsor and be held responsible for the success of the project?

If not, STOP YOUR PROJECT!

Refuse to work on or manage a project that doesn't have motivated, skilled, properly trained team members. Better to kill a project (or recommend one to be killed) than to be the one that hears the words "You're Fired" when the project fails.

Good Website

In case you haven't heard the Ten Step website has some excellent free project management white papers and templates, and additionally they license (for a fee) a number of Project Management Methodologies (TenStep, PMOStep, SupportStep, etc). The prices are reasonable, and I personally have licenses for the TenStep and PMOStep methodologies and can highly recommend these for new or experienced project managers.

I have no affiliation with this site, but use the content and have found it to be an excellent source of project management information. If you visit the site let Tom Mochal (President of TenStep) know I sent you.

Tom has just recently written a book entitled Lessons in Project Management, and from what I understand it has received rave reviews. I will be purchasing a copy for myself within the next few weeks.

Until next time...

What Makes a Successful Project?

The four measurements that must always be used are:

1.) The customer is satisfied

2.) The project is delivered within or under budget

3.) The project is completed on time

4.) The project's requirements have been met

Keep in mind the most important measure of project success is Customer Satisfaction. If you deliver a project on-time, within budget and it meets all requirements yet the customer is not satisfied, the project is a FAILURE!

Keep your customers (stakeholders/sponsor) informed throughout the project. Communicate to your customers using face-to-face conversations (yes, good project managers actually do this), status reports, e-mail, status meetings, voice mail, formal documentation, even sky writing if you have to. Your customers must be kept informed and remain engaged throughout the project. If you aren't hearing from them during your project, you aren't communicating with them. We all know that effective communications are two-way. If members of your project team choose not to communicate with you during your project look to have them removed from the team immediately.

In closing, maintaining a dialogue with your customers throughout your project helps you to address concerns and issues quickly. Combining effective communications and management of the project's triple constraints (Time, Cost Quality/Requirements) will help to ensure that your customers are satisfied with the end result of the project.

What is Not in Writing Has Not Been Said - Part II

A subject of one of my previous posts contained the quote "what is not in writing has not been said". While you may not want to make that statement to your boss when asked about your last conversation, there are many times when this statement is applicable during your project's lifecycle.

A project manager’s main function is to complete his or her project on time and on budget. This takes teamwork and a strong commitment by all team members. To be a successful project manager you must use written communications to ensure the team is kept informed.

Having said that, just because you go to the trouble to document your thoughts does not mean that your communications are clear. The receiver of your message will act on the message they think they received, which is then filtered by the receiver through their emotions and assumptions.

Don't be as concerned with what your words mean, but more with the effect they will have on the people that read them.

An important fact when writing, "Know Your Audience". If the tone of the message reflects the audience's needs you are more likely to grab the reader’s attention and keep it longer.

Most of your readers are overworked, underpaid, unappreciated, and tired of reading all the e-mails, memos, and office correspondence they receive. While this may see extreme, keep it in mind when writing your message and you will tend to keep your messages focused to the point and brief.

Team Communications

How clear are your Project Communications with your project team? As we all know, project teams are made up of diverse individuals with different skills, priorities, and needs. Project teams need timely, clear communications in order to function as a cohesive and productive group. While managing your project, you should focus your team communications to address the following areas:

Accountability - What are the team members accountable for? Which tasks and/or deliverables is each team member responsible for delivering?

Approvals - What decisions are the team members authorized to make? What type of communication needs to be sent by the project manager to the team when project approvals have been made?

Synchronizing - Timely and accurate information needs to be provided to the team members regarding the project's tasks and milestones. Special attention must be paid to how the work is coordinated so all team members are working on the right things at the right times. Include the team when making decisions about synchronizing the work.

Progress Tracking - The project manager is responsible for tracking project status and the team must participate in the status reporting process and be kept informed. Ensure that the team is aware of the project's issues and allow them the authority to take remedial action to avert a crisis.

What is not in writing has not been said

While the title of this message may seem extreme, there are many times when it is relevant in project management. One example is in the area of requirements. Project requirements are always in written form. In the field of project management there is no such thing as a verbal project requirement.

The following text was taken from Chapter Twenty in the “Field Guide to Project Management”. The authors Francis M Webster, Jr. and Stephen D. Owens state, "the written document provides instructions, restates previous instructions, conveys importance to the message, and helps the project manager to cover their tracks".

The authors also make the point that that "e-mail isn't always enough and can get you in trouble faster and with more people". As we all know from experience, e-mail usually isn't given enough thought before it is sent which can lead to messages being misinterpreted and having unintended consequences.

A project manager that is doing his or her job will formally document all items that are important and relevant to supporting a project's triple constraints (Time, Cost, Quality).

Project Objectives and the Work Breakdown Structure

I talked earlier about a Work Breakdown Structure (WBS), but this is such an important subject it is valuable to revisit.

The WBS should accomplish several things:

It is the mechanism that takes the project's requirements and turns them into manageable project tasks

It is used to communicate project objectives to the project team and other stakeholders

Its output is used to build your first plan and schedule

In David I. Cleland's Book "Project Management: Strategic Design and Implementation. Second Edition" he states that:

In general the development of the WBS provides the means for:

Summarizing all the deliverables , resources, and activities of a project

Relating work elements to each other and to the total project

Building the matrix organization for the project by cross referencing the work elements to the organizational resources responsible for their completion

Addressing all contracted resources required for the project.

Estimating costs, simulating project scenarios, and conducting risk analysis

Providing information to define, budget, schedule, perform, and control work packages

Definition: "Work Package" - A deliverable at the lowest level of the Work Breakdown Structure.

Keep in mind a complex WBS isn't' required for most small and medium sized projects. Many times a simple deliverable-oriented tree of activities that graphically displays the work to be done will suffice. By that I mean a structure similar to an organization chart with the project name on the top row and the second row consisting of some elements of your project methodology.

For example, for an IT project the second row headings might be:

Analysis

Requirements

Design/Procurement

Coding/Installation

Test/Acceptance

Close-out.

The best way to get started with creating a WBS is to gather the team (always done with the team) and write down the project tasks on Post-It Notes. Then, use an available wall to post the tasks in the appropriate places under the headings of your WBS's second row.

Project Management Boulevard

Another good Project Management site with an extensive, usable library of White Papers.

Project Management KnowledgeBank

Here is a link to a site I use quite often. It contains lots of links to other Project Management sites that have some useful information. Project Management KnowledgeBank

Project Management and Disaster Planning

Had you been a Floridian this past week living on the southwest Gulf coast like I was, you would have quickly realized that Disaster Planning was something you should have completed months if not years earlier. It turned out that Hurricane Charlie was a major disaster for thousands of families in our area. I wonder how many might have lessened their troubles if they had done some disaster planning prior to this tragic event.

As my wife and I scrambled around the house on Thursday night taking pictures and recording serial numbers of our possessions, I quickly realized I should have prepared a disaster prepardness plan long ago.

As most of us know, one of the most important things to have when planning for any project is a scope statement. My scope statement for this hastily started project was simple: "keep my family safe and protect our property". I live in a new house, and with the strict Florida building codes that were enacted over the last several years I felt we were safe staying in our home. But, like most projects, my plan was full of risks, and I needed to perform some serious Risk Mitigation. Did I have fresh batteries for the flashlights, a portable radio, a designated safe area of the house to escape to in case things got bad?

On Thursday evening the kids filled the bathtubs with water (in case we lost our water supply), we made sure there were candles and matches (in case the electricity went out), my wife took the time to ensure the propane tank for the gas grill was exchaged for one that was full, and she went to the store and purchased plenty of canned goods and bottled water. To further mitigate risk, my wife and I filled our cars with gasoline and began clearing the yard and lanai of objects that could become flying missiles in a strong wind.

Having said all this, it would have been much better to have had a well thought out plan, or checklist prepared ahead of time so that no important task would be left undone. While our immediate area wasn't impacted much by the hurricane, the lesson learned from this experience is that early planning is not only important, but it can save a lives!

God Bless the families impacted by Hurricane Charlie!

Will the real Project Sponsor please stand up?

In my experience most projects don't have a real project sponsor. A project sponsor is the senior manager or executive that champions the project in the organization. The sponsor provides support for obtaining resources, provides strategic direction, and acts as the decision point for questions outside of the project manager’s authority.

Every project that crosses functional lines of authority needs a project sponsor to remove barriers, assist in resolving conflict, and mediate negotiations. The sponsor can also act as a mentor and coach to the project manager and team members.

The project sponsor is usually chosen by senior management, but sometimes the sponsor volunteers because the project directly impacts their resources or budget the most.

Typically Project Sponsors are responsible for:

Providing project direction
Monitoring project progress
Assisting the Project Manager to define the Project Management process for the project
Approving final scope, project objectives, schedule, resource assignments, roles and responsibilities
Providing accurate, relevant and timely communications in writing when appropriate
Approve scope changes
Obtain or resolve issues surrounding resources (people, money, equipment)
Setting project priorities and removing barriers to project success

Project Management Truths

I found these "Project Management Truths" several years ago on the Internet . Here is a partial listing, I will post more later.

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.

Any project can be estimated accurately (once it's completed).

The most valuable and least used WORD in a project manager's vocabulary is "NO".

The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".

Nothing is impossible for the person who doesn't have to do it.

You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.

At the heart of every large project is a small project trying to get out.

If you don't stand for something, you'll fall for anything.

The more desperate the situation the more optimistic the situatee.

Six Steps to Political and Project Success

Assess the Environment

    Who are the relevant stakeholders?

    Who are the most important stakeholders?

    Where does the power lie?

    Whose actions will impact the project most (Negative or Positive)?

Identify the Goals/Needs of the Stakeholders and Sponsor

    What are the stakeholder's/sponsor's work and/or organizational motivations?

    What are their psychological motivations?

    What is their overt motivation?

    What is their hidden agenda?

Know Thyself

    What are your strengths and weaknesses as you perceive them?

    How are you perceived by others?

    What are your personal values related to your workplace?

    How can you compensate for your weaknesses (actual and perceived)?

Define the Problems

    What are all the relevant facts?

    What are the underlying assumptions (both True and False)?

    What is Reality?

Develop Solutions that Work

    Avoid premature solutions that don't account for the four steps above

    Obtain user buy-in to the solution

    Obtain Sponsor buy-in to the solution

Test and Refine the Solutions

    Initial solutions are tough and usually difficult to sell

    Continually refine and test your solution

    Get sign-off from all relevant stakeholders and your sponsor

__________________________

PROJECT MANAGEMENT FACT

A solution that does not take the realities of the political environment into account will fail.  Don't be naive when it comes to internal politics.

Quality Guide - Welcome to Managing for Quality

Quality Guide - Welcome to Managing for Quality.

Here is a site that has some great information regarding Quality Management.

Michael Greer's 20 PM Actions/Results

Michael Greer's 20 PM Actions/Results

This looks like a good site for general Project Management Information. Give it a try and let me know what you think.

Good Requirements Management = Increased ROI

What of the biggest areas of concern in the IT Project Management field is Requirements Management.  It has been said that reducing requirements errors can have the biggest impact on delivering a quality software project on time and on budget.  How do you as a Project Manager help to reduce requirements errors while not slowing down project progress? 

Before we answer that question lets look at some industry statistics. 

According to the Standish Group (over 352 companies reporting on over 8000 projects):

• 31% of all software projects are canceled before completion
• 53% of all projects will cost 189% of the original estimate
• 9% of projects are delivered on time and on budget (in large companies)
• 16% of projects are delivered on time and on budget (in small companies)

The reasons given for the above are:

• Lack of user input or participation - 12%
• Incomplete Requirements and Specifications - 12.3%
• Changing requirements and Specifications - 11.8%

To answer our question stated previously, what can a Project Manager do to reduce requirements errors? 

Try the following:

• Structured  requirements gathering meetings
• Walkthroughs and reviews of requirements with end users and customers
• Better organization and documentation of requirements
• Improved project progress reporting
• Improved requirements-based testing and requirements tracability

If you will implement the above suggestions you can reduce requirements errors by 20% or more.  Any reduction in requirements errors will help to significantly reduce project cost and schedule overruns.

The Project Management Office

Many companies are implementing a Project Management Office (PMO).  If you or your company are thinking about starting a PMO there are a few critical things you must consider. 

First, there is no right or wrong model for a PMO.  The issue is which PMO type is right for your organization and have you done the proper planning up front before implementing a PMO. 

Before you decide on the type of PMO that is right for your company consider the following:

Do you have a Mission Statement for your PMO?

Do you have a Vision Statement (can be covered in the Mission Statement)?

What are the PMO's Principles (what statements will guide how the PMO will achieve its Mission)?

Who are your Customers?

Who are the Stakeholders (those people or groups that will be impacted)?

What are the Goals of the PMO (what does the PMO hope to achieve)?

What are the Objectives of the PMO (must be S.M.A.R.T)?

Note: S.M.A.R.T Objectives are (S)pecific, (M)easurable, (A)ttainable, (R)ealistic, (T)imebound

Other things to consider are what Products, Services, Roles and Responsibilities will be offered by the PMO.

Once all of the above items have been finalized you are ready to build a Workplan that outlines the activities to make the PMO a reality.

What is a Work Breakdown Structure?

A Work Breakdown Structure (WBS) is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project work: work not in the WBS is outside the scope of the project. 

The WBS is often used to develop or confirm a common understanding of project scope.  Each descending level represents and increasingly detailed description of the project elements.  What does the WBS look like?  Work Breakdown Structures s are communicated and organized in many ways. 

The two most common ways to communicate a WBS is either a hierarchy diagram or a table of contents (TOC) layout.  In some cases both formats are used to gain understanding and define the work to be performed.  Typically, complex projects with a large number of internal and external stakeholders respond better to a hierarchy diagram. 

However, to understand and accomplish the specific work tasks, the project team responds better to the TOC layout.

To view more information about a WBS and see an example of a WBS click here

Common approaches to Developing the WBS

The two most common approaches to developing the WBS are the top down approach and the bottom up approach.  Some find a combination of both beneficial.

Top-Down Approach

The top down approach uses a predefined product development lifecycle, or a WBS template, or a WBS from a previous similar project as structured models to define the WBS from general to specific.  This approach involves using a model and reviewing the major project deliverables which have been subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project phases (planning, executing, controlling, and closing).  

Bottom-up Approach

The bottom up approach uses a planning group to brainstorm the work elements that are needed to deliver the major deliverables of the project.  A planner then groups the output from the brainstorming sessions into phases, activities and tasks.   The bottom up approach involves using a small group of people (5-6) who have some subject matter expertise to plan the project. 

The technique uses the brainstorming method to identify the work needing to be performed to deliver a specific thing.  When the project is large or complex, the brainstorming activity is focused on a major deliverable or end product instead of the broader scope of the project.   The results of the brainstorming session, generally are the pieces of work or tasks that the group knows needs to be done.  It is similar to creating a “to-do list”.  One of the planners then takes this information and groups the related work. These groups may then be grouped again to build up to the highest level of definitions.  The information is reviewed with the original group and they modify, fix, and add any missing pieces. 

Project Estimation

As stated so eloquently by Bob Lewis in his book "IS Survival Guide", There is no way for you to successfully estimate projects. Take that as a given. It can't be done, and for a very simple reason: Every one of your projects is one-of-a-kind. Mr. Lewis makes a very good point, however in my experience, I have yet to have met a manager that will let me get away with saying "I can't estimate this project".

SO WHAT IS A PROJECT MANAGER TO DO?

I like to call the solution to this problem rolling-wave estimating. By that I mean when the project is in the initiation phase and you have very little information your estimate should reflect that fact. This means very early in the project your estimate(s) could be off by as much as +200/-75% (or more). As you progress through the project planning phase you will breakdown the project into smaller, more manageable pieces of work (decomposition). This process helps to narrow the range of your estimates.

Do not be fooled into thinking that because you have broken down your project into phases and/or small manageable pieces of work that you can just add up the estimates and have a total overall project estimate. Many times, especially on IT projects, there are integration issues that are difficult to estimate and are usually ignored in the planning phase. Do not forget to add time for these critical integration activities. Also, while padding of estimates is a no-no, don't forget to account for Risk in your project estimates. PMI advocates for contingency and management reserves to account for risk events, but I have not worked in an environment where these exist so I have to plan for Risk in my estimates.

Be smart when estimating and realize that in the IT world estimates are always wrong and tasks are always underestimated.

Managing a Project in Steps

Everyone should know that for an initiative to be considered a project it must have an actual start and end date. Additionally, the project must needs a scope statement, budget, and resources.

The work in a project is considered to be unique. There may be similarities to previous projects, but no two projects are exactly the same because you will always be dealing with different circumstances and resources.

There are many different ways to manage projects and organize the work. We want to manage projects in an organized fashion using a methodology that has either been tested by others, or created for our own environment.

Step I use to manage a project are:

1. Define the Work (Concept Documents, Business Case, Charter)
2. Create the Plan (WBS, MS Work, Project, Excel)
3. Manage to the Plan (Earned Value)
4. Manage Issues
5. Manage the Scope (from the Scope Statement)
6. Manage Communications (Status Reports, Meetings)
7. Manage Risks (Risk Management Plan)
8. Manage Documentation (Document Management, Intranet/Internet)
9. Manage Quality (Quality Plan)
10. Manage Metrics (Status Reports, Earned Value)

It is important to remember as the complexity of your projects increases you will need to delve deeper and deeper into the Ten steps listed above. An excellent resource that explains how to use the above process steps is http://www.tenstep.com.

Commitment

While getting ready to leave for the day I was reminded of a quote by Tom Peters, "Commitment, not authority produces results". All project stakeholders need to be committed to seeing that a project's objectives are met, but more importantly they need to be open, effective, and honest when it comes to their communications with the other team members and management.

To support the project team and ensure their success, management must provide the best people to participate on project teams, and have a deep seated belief that the people on the team are intelligent, creative, and have the capability to succeed.

The entire project team and all levels of management involved must have the attitude that they will do everything possible to ensure that the customer (end user) is satisfied with the product of the project.

The number one measure of Project Success is Customer Satisfaction. Having a set of "shared values" will help a project team increase customer satisfaction for every project they support.

More Project Management Communications Information

According to the Project Management Institute (PMI), "Project Communications includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It provides critical links among people, ideas, and information that are necessary for success. Everyone involved in the project must be prepared to send and receive communications, and must understand how the communications in which they are involved affect the projects as a whole".

What does this mean in the real world? Keep those that need to know informed. Use face-to-face meetings, phone calls, e-mails, status reports, project status web sites, meetings, and other ways to keep users abreast of project progress, issues, and concerns.

Be aware that on many projects there will be stakeholders that are out to sabotage your project. Sometimes these actions will be obvious, and sometimes the signs will be subtle. Occasionally the saboteur doesn't even realize the damage they are doing. It could be just the way in which they go about doing their job. They may be confrontational with everyone they work with and they may not care what others think. Be prepared to gently confront these stakeholders and escalate through the management chain if necessary to keep your project's communications effective and relevant.

PMI considers Project Communications to be very important. It is one of the nine knowledge areas as defined by PMI's PMBOK (Project Management Body of Knowledge). It is an area of knowledge you must master to be a successful project manager, and if you hope to pass the Project Management Professional certification exam.

Project Communications

Good communications are a necessity if you want to have success on your projects. You need continual, effective communications among all team members during the life of the project if you want to minimize problems with stakeholders.

Agreements must be made early on regarding goals, how problems will be addressed and solved, how resources will be managed, and how the expectations of stakeholders will be satisfied. Project Communications are conducted throughout the lifecycle of the project. When the customer creates a business case or project request they start the communications process and the activities that follow (Project Charter, Statement of Work, Work Breakdown Structure, etc) support the project's communications effort. All project teams need to keep in mind the four major communication areas they must support.

RESPONSIBILITY: Each member of the team needs to be aware of their role on the team and their responsibilities.

COORDINATION: Information among team members is shared and each member works to carry out their assignments in the time allotted.

STATUS: Progress is tracked, issues are identified, and action is taken to remedy any problems. Project status reports are distributed to all project stakeholders.

AUTHORIZATION: Team members must be kept informed about decisions made by customers, vendors, sponsors, and management personnel that relate to the project.

Initial Posting

As a project manager working for a County Government I am faced with challenges everyday that I didn't often experience in the private sector. Hidden agendas, internal politics, and silo mentalities make for an environment that has many pitfalls, but also many rewards.

In the seventeen years I have been a project manager I have prided myself on my ability to work with others towards a common goal. I feel that a project manager's greatest attribute is his or her communication skills and the ability to be flexible when presented with a challenge. My goal in creating this BLOG is to pass along some of my thoughts and learnings, which will hopefully help you to avoid repeating the mistakes I have made over the years.

Stephen Seay, PMP