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.

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.

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!

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.

As an IT project manager, if your system or application is integrated with sensitive data of any type you should be thinking about security. Sensitive data consists of credit or personal information as the general public is most commonly aware of. Other types of sensitive data on the corporate side would be sales information, trade secrets and patents for example.

In February of 2007 it was revealed that a scientist within DuPont stole $400 million worth of trade secrets. A Carnegie Mellon study found that many employees with new job offers often take information from their current company before they leave for their new position. In April of 2007, the social security numbers and birth dates of 2.9 Million Georgia medicaid recipients went missing in transit. The TJ Maxx credit card cyber-thief had the encryption key but may not have needed it since the data was stolen prior to encryption.

In reference to the 2007 study, only six percent of the 1,408 companies surveyed could categorically state that they have not lost any data in the last two years. While many companies are concerned with attacks by hackers, 61% of those surveyed felt that data loss was due to insiders. The survey indicated that 55% of data leaks are intentional. The survey also indicated that 23% of a corporations data loss is malicious. One area the report overlooked was employee resignations. There is the likely potential that this is a high risk group of corporate data leaks.

What this means to organizations is that data security needs to be analyzed in all areas of an organization and not just in the IT department.

For Project Managers …

• Data used by applications or system solutions needs to be classified and managed accordingly.

• Proper controls need to be in place to determine who has access to what data.

• Monitors should be in place to track or block access to sensitive data.

• Data flow through email, messaging, FTP or any other web protocols should be monitored.

• Enforce corporate data policies. (If policies do not exist, create them and enforce them. Train the employees on data policies. This may be out of scope for the PM, but a suggestion to the corporation.)

This is just a short list of security concerns for the IT Project Manager.

The information presented here is based on a report I created in August of 2007. Even though this is based on a two year old academic report it is still relevant for today’s IT Project Manager.

For more information on IT Data security measures please visit …

http://csrc.nist.gov/

and

http://www.iso.org/iso/catalogue_detail?csnumber=39612

1) Think of what you are good at, what would you have to do to achieve excellence?

2) Now think of what you are good at, what do you have to do to in order for it to be nothing but perfect?

Take some time with this exercise and write down what you would have to do to attain excellence vs. perfection.

Here is a concept that may assist you in this thought process. Work within the tolerances. What this means is that you can create something that works without perfection. Here are a couple of examples …

1) Your automobile, your bicycle your home is not perfect. They are all manufactured or built within tolerances.

• The engine in your car is assembled with parts that fall within acceptable tolerances, they are not perfect.

• Two identical bicycles could have their brakes adjusted differently but they still work.

• Your home has any number imperfections around windows, corners and doors but do you really notice them?

2) When you bake a cake from a recipe or a box you follow a recipe. Though you may repeat the recipe over and over again, it is not done with perfection.

• Most cake recipes require an egg. Is there a perfect egg? Do you obtain the perfect egg every time?
• How about those measuring cups? Do you hit the mark each and every time you measure an ingredient?
• Is your oven temperature spot on each and every time?

To summarize this, we live in a world of working within tolerances yet we can achieve excellence by doing so without the need of striving towards perfection.

Work within the tolerances and strive for excellence!

Many of us in Project Management have heard the term SMART Goals but a quick review may be beneficial from time to time. The word SMART is an acronym that is broken down into …

S – Specific

M – Measurable

A – Attainable

R – Realistic

T – Timely

Please note that there are other variations of the SMART acronym but I find this version best suites me personally and professionally. With that in mind, I would like to break this down a bit further.

S – Specific, I feel that this should address the who, what, when, where and why of the SMART goal. In other words …

Who needs to be involved to accomplish the goal?

What needs to be accomplished?

When does this need to be completed by?

Where does this need to be accomplished?

Why does this need to be accomplished?

M – Measurable, I feel that this should measure the progress of the goal. It should be a periodic scheduled review that is measuring what is being accomplished over time.

A – Attainable, I feel that this should determine if this is something that can truly be accomplished. It is important to remember that goals take time, money and resources to accomplish, it is not something to be taken lightly by the organization or individual.

R – Realistic, I feel that if the individual, the team and/or the organization believes that the goal is realistic than it can be accomplished.

T – Timely, I feel that a goal without a deadline or schedule will not get the attention it deserves and will most likely not get accomplished.

These are the SMART goal criteria that have been advantageous to me over the years. But I want to focus on something I have found very important and that is … “Why does this goal need to be accomplished?” If you don’t have a big enough reason why this goal needs to be accomplished, chances are you will not get the engagement or traction necessary to get moving on the goal.

My advice is to be clear about SMART goals and periodically measure their progress over time. I feel that we all desire the successful outcome for individual and team goals, if there are written status reports and scheduled periodic reviews of goals this will lead to a successful outcome. Take a look at the calendar, when did you last check the status of your goals? In addition, how are your goals coming along? This is something you may want to think about.

Let’s use the planes in this photo for example. People are required for a successful outcome. Process is required to create, repeat and maintain the presentation. Performance is required to track the operation technically, mechanically, individually and as a team. If any of these are missing, the end result could be much different.

In my article, “The Three P’s of Project Management” I provide more detail on each topic. The link provided is to the site that I originally posted the article on. I look forward to your feedback and insight.

The Three P’s of Project Management

The Three P’s of Project Management Published on Project Smart

As I read through the document I found many areas that I felt could use some improvement. I made many recommendations and only one was rejected. Afterward, I knew I did the right thing by taking the time to assist the team of professionals to produce the best PMBOK to date. I am grateful to find my name listed with several other respected Project Managers in the industry in this version of the PMBOK.

Since the PMBOK Guide–Fourth Edition is a requirement for passing the PMP exam, I strongly recommend a thorough understanding of the content.