Many Thanks

I want to thank my Twitter friend @Soma_b for posting this interview to her Blog. It was a pleasure working with Soma on this and I am very pleased that Soma asked me to do this interview. I highly recommend PM’s and those interested in Project Management to consider reading her Blog. You will find it informative and insightful.

The Project Blame Game

Just remember that every time you point your finger at someone there are three fingers pointing right back at you. The blame game can be seen in most organizations that struggle with projects. The blame game is something that we play as children and some master in as adults. In order for projects to be successful this game needs to be obliterated, truth of the matter is, the blame game may always exist. Let’s face it, if a project starts falling behind and/or gets into a crisis situation, members of the team will start looking for someone to blame. At some point in time the crisis will become visible to the powers that be and they will want answers. I am sure that at some point in time many of us have seen this happen.

I would like to look at the blame game from a couple of angles. The first example is the blame game in an environment without a good Project Management Methodology in place. More than likely project scope is mismanaged, documentation is poor or non existent, no change control procedures and on and on. Keep in mind these are just a couple of examples, there could be countless other examples to use for reference.

Here is something likely to occur, I told him (her) what I wanted and what I got is not what I asked for. Without a scope document to refer to you will end up in a finger pointing game and team members disgruntled with each other. You may have to take someones word for it or just take the extra time, money and effort to fix it. This activity prevents other projects from beginning and has a negative impact on the corporate financials. Think about this for a minute, do these parties want to work on future projects together after this experience? What does this do to the moral of the team? What impact does moral have on the success of your business?

Let’s look at another example in an environment where a good Project Management Methodology exists.

Biz Unit Manager: I told him (her) what I wanted and what I got is not what I wanted.

PMO Manager: Well let’s take a look at the scope documentation and use cases. What specifically is it that you wanted that you did not get?

Biz Unit Manager: I wanted the data to get entered into the XYZ database so it could be analyzed by the diamond reports application and not impact production during business hours.

PMO Manager: OK, where is that stated in the project scope?

Biz Unit Manager: Well, it’s not.

PMO Manager: Are there any use cases to reference?

Biz Unit Manager: No, there’s not, but I asked Joe Devmaster for it.

PMO Manager: Did you provide the information in a change control request?

Biz Unit Manager: No, I didn’t have time.

PMO Manager: Well, Looks like Joe didn’t have time to remember it either. Let’s get the change request made and properly approved so Joe can work on this. Do you realize that this extra work may cost $5,000 and will impact the start date of your next project?

… Thus begins another conversation.

Do you see the difference in these examples? Can you think of examples in your own environment of the blame game? If the protocol of the PM Methodology was followed in the second example some items could have been addressed and managed earlier in the process and the project could have run a lot smoother. One question I have is, what does your company do with staff members that thrive on the blame game and continuously wreak havoc on corporate projects?

There are several levels of how the blame game is played in various organizations. If a good PM Methodology is in place and effectively utilized, many projects will run smoother. Without effectively utilizing a PM Methodology projects will be managed in chaos and relationships and moral will deteriorate. The cost to this is turnover and loss of expertise. Can you afford that in any economic time? It may be something to think about.

Project Guessing

As project managers we realize that there are several types of risk involved in projects that should be recorded in the Project Risk documentation. There are times however that results or events are predicted without sufficient information and we run down the path of guessing. If anyone on the team tends to assume, presume or assert facts without sufficient information, the project outcome can be less than desirable.

Guessing on projects in most cases may lead to errors that end up having an impact on the project scope, schedule and budget. Without clarity and an accurate course of direction you may end up writing more use cases at the time you thought the project was going to end.

What may cause this problem is the lack of formal Project Management (PM) integration. For some companies, using small portions of PM methodologies may have been successful in the beginning and this is fine if a company is not in a growth pattern that needs additional structure. However, if there is growth and maturity over time, most likely the PM needs will change also. If action is not taken at the right time, the art of process integration becomes more challenging and costly as time goes on.

The solution to resolve this issue may vary from company to company for a variety of reasons too lengthy to list in this article but here are some things to consider …

* Are efforts taken to reduce the guessing factor such as the five “why” questions?
* Are the current PM methods in use by the company effectively managing the scope, schedule and budget of the projects being managed?
* Are there processes in place to govern projects and manage them effectively?

If a company is struggling in any of these areas this may signal the need to identify issues and take corrective action.

By performing the proper analysis, a company can identify the steps and actions necessary to implement in order accelerate development time, reduce costs and improve quality by reducing or eliminating the guess factor. Look around your environment, are there things you can improve? Take some time and think about it.

Project Understanding

There may be times as a Project Manager that you may have to work with people (*resources) that may not have a clear understanding of a project or portions of a project. This can really happen and for some, it can be very frustrating.

Some team members may struggle with understanding the project scope; others may struggle with understanding a function or design. These are just a couple of examples. If this occurs remember that a display of frustration will not lead you down the road to success.

There are several courses of action that can be taken in this situation. I have found it best to meet one on one with these individuals in an effort to assist them and sometimes myself. For example, I have had to meet with others to discuss the capabilities of an application design or technology so that the best decisions can be made. I have also had to meet with others so I have a better understanding of a business process that needs to be incorporated into an application.

It would be negligent of me if I chose to remain clueless and try to make decisions on a topic I have no understanding of. This is why I take the time needed to have a solid understanding of the project so that great decisions are made. As a project manager we may need to be in a position to assist others at times so they too can make great decisions. There may be times when we may need to solicit SME’s if we are not the subject matter experts. This leads to a better understanding by all participants. Better understanding, better decisions, better project success.

*resources – I had some interesting Twitter discussions about the use of this word. I understand that the Agile community may not favor how I chose to use this word and I can understand this to a degree. By the PMBOK definition I have used this word appropriately. Agile may say that people are people not resources. If that is the case, how many Agile people have avoided the Human Resources department to gain employment? Is semantics so misunderstood?
Special thanks to @michaelbolton and @AgileForAll for lessons learned this week!

Project Acquiescence

If one or more team members are resistant or in disagreement to a project decision and agree to the decision without protest this may be considered acquiescent. There are several project problems that can be encountered if a team member is acquiescent, some examples may include …

1) A bad decision made based on lack of information

2) Team disgruntlement if acquiescence is discovered, and

3) Bonds of trust may be broken.

It may be difficult to identify acquiescence among team members; silence is not necessarily an indicator of acquiescence. However, outside of team meetings, the project manager may want to meet with individuals and have discussions about the project to gain additional information.

If additional information is obtained, it can be shared with the group and the individual can be recognized as a contributor if the situation is handled properly.