Search This Blog

Monday, April 30, 2012

Does Your Project Have Value?

Are you working on a project that has diminished in value? Does your project seem like it would have been a good idea if it was implemented two years ago, two years from now? If you are questioning the value of your project think about these things.

What would happen in your company if the project were cancelled?

Does the project link to your organizations strategic goals and/or objectives?

Does the project have visible support from senior management?

Does the project generate excitement?

Is your organization going to gain efficiencies or be more competitive as a result of successfully completing the project?

Is there lots of negative "buzz" about the project?

I'm sure there are lots of other questions that could be asked when it comes to questioning the value of projects. We need to keep in mind that all projects eventually end. Some end when they are completed successfully, and others are terminated early for a variety of reasons.

The important thing to keep in mind is that you must continually communicate across, up, and down the organization to find out what others are thinking about your project.

If the project manager is the only person in the organization that thinks his or her project has value, then the project manager isn't really thinking.

Does your project still have value? A tough question for certain projects, but one that must be answered on a regular basis.

Monday, April 23, 2012

Project Management - Communicating Change

Think about these questions prior to communicating change to your organization, project team, or stakeholders.

1. Why are we changing things?

Be prepared to address the value of the change to the people impacted by the change

2. What is required for those impacted by the change to do? What needs to be done first, second, etc.?

Outline the steps required to implement the change

3. How will we measure the results of the change? What are the potential impacts?

Prepare ahead of time to address how the team will know if they are successful.

4. Once change is implemented what tools or processes will need to be changed, added, deleted?

What will be impacted and how might these changes be received?

5. What is the benefit of the change (What's in it for me?)

What is the benefit, what is the downside (if any)?  Be honest and let the team know if behavior change is expected

Tuesday, April 17, 2012

Assumptions vs. Facts

Dr. Lewis Ireland wrote the excellent article below in 2003 talking about the differences between Assumptions and Facts.


The difference between an assumption and a fact is often subtle and confusing. Some organizations, and individuals, view assumptions and facts in the same light. This approach causes confusion in managing both the assumptions and facts as well as communicating accurately the situation during planning and execution of projects.

The American Heritage Dictionary defines both words in the context of planning as:

• Assumption – a statement accepted or supposed as true without proof or demonstration.

• Fact – something presented as objectively real or something that has been objectively verified.

Planning a project using the wrong term can convey a different meaning to fact or assumption with catastrophic results. Facts do not change whereas assumptions are typically about a future state that may or may not come true. Listing both facts and assumptions as assumptions can also cause confusion because the project manager does not know which assumptions to track to ensure they are converted to facts.

read the rest of the article by clicking here

Thursday, April 12, 2012

Quote for the Day

You've got to have an atmosphere where people can make mistakes.  If we're not making mistakes, we're not going anywhere.  - Gordon Forward

Monday, April 09, 2012

Where are your Process Maps?

Well crafted business process maps should be designed to make work flow visible, understandable, and measurable. An important consideration when mapping your business processes is to view them through the eyes of your customers.

Here are some areas to consider when you are mapping business processes:

Identify Your Organization's/Project's Business Processes

What are the processes in your organization that your project will impact?

What new processes will be created once your project is implemented?

What are your customers understanding of your processes?

What are the key trigger points of your processes?

Gather required information

Who are the process owners?

What are the processes you've identified trying to accomplish?

What is the level of quality required? Risk?

What are the control points?

Documenting the Processes

What are all the steps of the processes?

What are the objectives of the processes?

What are the inputs and outputs?

What tools or techniques are applied in each process step?

Where does the process begin and end?

Who owns the process?

Who monitors the process?

How we will know it is working?

Analysis (post mapping)

Is the process efficient?

Does it make sense?

What steps are unnecessary?

Is the process in line with departmental or enterprise objectives?

Are there too many approvals or too much rework?

Are there too many delays or bottlenecks?

Is the process efficient? How do you know?

What measures will be put in place to ensure the process is as efficient as possible?

There are many opportunities for problems to occur when mapping processes, but getting started will help your organization become more effective. Once you become good at mapping your business processes everyone in your organization will begin to understand their role in the organization, what the organization it trying to accomplish, and feel like they are part of the effort to help drive improvements and efficiencies.

There are plenty of books on the subject to help your get started. Click the link below for books that can help - Process Mapping Books

Saturday, April 07, 2012

Monday, April 02, 2012

The Project Sponsor

A project sponsor's role is to help make project decisions (formal authority), and additionally, he or she is ultimately responsible for the project's success. The sponsor comes from the executive or senior management ranks (depending on the size of the project) and should be influential, a respected politician, and have a track record for getting things done.

The sponsors authority and stature should be such that they are independent as much as possible of the project's goals and objectives so they can cut through the political landscape to get critical project decisions made.

Sponsors don't just support projects; they support the project manager and project team. They are the project champion and won't allow others to sabotage the project manager, the project team, or the project's goals. They have authority that comes from their title and position within the organization. In order for sponsors to be effective they must have organizational respect, proven leadership qualities, and be honest in their dealings.  They aren't political sharks and they are adept at rallying the troops (project team and stakeholders), presenting a clear message, and are supportive of the project manager.

Ideal Sponsor Responsibilities

Writes the Project Charter

Help to define project team roles and responsibilities

Acts as an advisor to the project manager

Removes obstacles

Has control of project funding

Reviews and Approves any Statements of Work/Contracts and Planning Documents

Bad Sponsor Characteristics

Always too busy to meet with the project manager and project team

Doesn't have time to write a project charter

Won't get involved in assigning project roles and responsibilities

Doesn't have time to approve documents, or delegates all sponsor responsibility to others.

Blames others when things go wrong, and/or won't work to resolve project issues

Always takes credit for any project success

Is surprised when the project's deliverables aren't what they expected

A bad sponsor is a project manager's worst nightmare. Avoid them at all costs if possible.