Search This Blog

Wednesday, September 20, 2006

VUGs and Projects

I like the quote by Malcolm Forbes that goes, "You can easily judge the character of others by how they treat those who can do nothing for them". I have been fortunate over the years to have worked for people that had good character and lived by high ethical standards. At the same time, I have worked with and for people that only care about their own vague agendas, that speak mostly gibberish (technobabble), and refuse to acknowledge the accomplishments of others. I call these people, "VUGs". VUG is an acronym for Vague, Unclear, and Gibberish- speaking.

I'm sure you know a few VUGs. They come to meetings, (they love e-mail) and try to prove how smart they are by using "industry" jargon, corporate gibberish-speak, and what has been referred to as "technobabble". They are generally laid back, often personable, will complement you to your face, and put you down behind your back. They are insecure, generally soft-spoken, power hungry, yet calm in the face of crisis. They blame others, never apologize, and love recognition. When they do try to recognize others, it is usually out of guilt or a sense of corporate duty.

VUGs like unclear (immeasurable) strategies and objectives. They ensure that they can't personally be held accountable because they speak in vague terms and future perfect scenarios. Timeframes usually aren't important to VUGs. In fact, they will never state a definitive deadline for anything that can come back to bite them. They love to delegate, are unwilling to debate, and are usually unable to deal effectively with others because of a lack of self-confidence or guilt from the way they have treated others.

VUGs speak in VUGlish, a language all their own. When VUGs speak what they say rarely has a connection to organizational strategy, is peppered with gibberish, or is a long-winded rambling of disconnected thoughts and ideas linked to immeasurable goals.

So what does all this mean? For the project manager, having a VUG for a project sponsor, as your manager, or as one of your stakeholders is inevitable. How we handle them will help determine how successful we are when managing our project.

As project managers we have to de-VUG our projects. We de-VUG our projects by ensuring that language in our scope documents, project plans, and other project documentation is:

Specific and Clear

Linked to Organizational or Departmental Strategy

Is Written in Plain Language

Is Measurable

Has Definitive Dates (deadlines) for all Milestones and Deliverables

If you are ignorant of the VUGs that can influence your project, your projects could get VUGly!

What do you think? Do you agree, or disagree? Do you know a VUG?

Leave me a comment or e-mail me.

I hereby lame claim to inventing the following words and phrases:

VUG, VUGlish, de-VUG, VUGly, VUGger, VUGliness, VUGinator, deVUGify, Coyote VUGly, VUGstard, VUGnation, StarVUGs, iVUG, VUGoogle

Anybody else have more VUGisms?

Monday, September 11, 2006

The Project Sponsor - The Good and Bad

Most projects cross departmental or enterprise lines of authority, and many projects get funding from more than one source. We all should know that projects are temporary endeavors undertaken to create a unique product, service, or result. It is the temporary nature and uniqueness of projects that make the job of project manager so difficult. Project managers must work with different groups of people (stakeholders) to meet project objectives, and usually don't have any much authority to get stakeholders to perform the project work. A strong project sponsor can help the project manager address the people issues (and many more project issues that will arise).

A project sponsor's role is to help make project decisions (formal authority), and he or she is ultimately responsible for the project's success. The sponsor should come 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. You don't want a "Political Shark" for a sponsor.

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. As mentioned before, they aren't political sharks, 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

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

Bad Sponsor Characteristics

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 issue(s)

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.

Tuesday, September 05, 2006

Project Management and Business Process Mapping

Hopefully, every project manager has been involved at one time or another with helping their customers map their business processes. Business process maps 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.

Four steps you can take to begin Process Mapping are:

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 to 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