Tips, hints, links, and helpful information related to the discipline of Project Management.
Search This Blog
Monday, October 09, 2006
Projects, Leaders, and Discipline
So why don't more organizations keep closer tabs on their projects at the enterprise level? Some would say the executives are too busy strategizing, and the projects are running just fine without their oversight. I think people that say this are fooling themselves and have little to no project management discipline. The data is clear that projects are delivered faster, cheaper, and with higher quality when projects results are reviewed by the enterprise (executives).
Before we go further, we need to ensure we have a clear understanding of the word discipline. Discipline is the act of encouraging a desired pattern of behavior. George Washington said: "Discipline is the soul of an army. It makes small numbers formidable, procures success to the weak, and esteem to all". In other words, discipline is the glue that holds organizations together.
We can't have agile and effective project methodologies or organizational processes without discipline. In short, effective discipline requires effective organizational oversight. Finally, discipline begins at the top and works its way down. Organizations with poor discipline have weak, ineffective leaders at the top. Weak, unengaged, ineffective leaders kill organizations. Can you say Enron?
The lack of project discipline is the fault of all project team members, but the cause of a lack of discipline lies at the top of the organization.
Disconnected, disinterested, and unengaged leadership is unacceptable in any organization. Undisciplined organizations have high turnover, low employee morale, and poor project results. These organizations cheat their investors and customers by not providing the highest level of service possible. Highly disciplined organizations make and keep commitments, manage to clearly stated and measurable goals, and have executives that are engaged and visibly participate in the oversight of projects and day-to-day operations. If you aren't visible, your aren't relevant. If you aren't relevant, you aren't needed.
In closing, dysfunctional organizations believe that the workers are solely responsible for managing projects and other day-to-day work. These organizations believe that the executives should spend the majority of their time strategizing and making policy. This is a failed approach (see General Motors, Ford, K-Mart, etc), and ensures the work, including projects, will take longer than planned and cost more than what was budgeted.
Executive leadership and oversight of projects has been proven to motivate project teams to be accountable, results driven, and focused on achieving a common goal. Good executive leadership provides the glue that keeps teams working together, provides inspiration, exhibits integrity, sets an example for others to follow, and is accountable.
Leadership is action, not position - Donald H. McGannon.
Monday, October 02, 2006
A Message by Bob Moorehead
Wednesday, September 20, 2006
VUGs and Projects
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
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
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
Monday, August 28, 2006
Important Words
The six most important words: "I admit I made a mistake"
The five most important words: "You did a great job."
The four most important words: "What is your opinion?
The three most important words: "If you please"
The two most important words: "Thank You"
The one most important word: "We"
The least important word: "I"
_____________________________________________
Important Words for Relationships
The six most important words: "I admit I made a mistake"
The five most important words: "You are everything to me"
The four most important words: "How can I help?"
The three most important words: "I love you"
The two most important words: "I'm sorry"
The one most important word: "Us"
The least important word: "I"
I ran across the "Important Words for the Workplace" while browsing my hard drive. I don't know where I found it, but I thought it was very good. Below the Workplace list you will find one my Dad e-mailed me years ago regarding relationships.
I list them here because part of being a good Project Manager is building trust among your team members, and an important part of building trust is being empathetic, and letting people know you care.
Tuesday, August 22, 2006
Pete's Estimating Laws
Pete's Estimating Laws - A Humorous Look At Estimating
This week's posting was found at Project Connections.com. While meant to be humorous, it has many facts that need to be kept in mind when estimating your project.
1. Everything takes longer than you think (sometimes a lot longer)
2. Thinking about everything takes longer than you think
3. Project Managing and leading a project team is a FULL TIME job, and then some
4. Software Engineers are always optimistic (generally REALLY optimistic)
5. Schedules are (almost) always wrong
6. If you under-estimated an early task when you wrote the WBS (schedule), you probably under-estimated middle and later tasks. Revisit the later phases of the schedule as early as possible when you discover early phase schedule (estimate) errors
7. Business types (upper management) REALLY do use your estimates for planning. For example, head count, money, customer deliverables, shipping dates, ordering materials, scheduling manufacturing lines, advertising timing, etc. Be able to express your level of confidence on various estimates when you provide them to others
8. Initially, a good schedule estimate is 80% confidence for near term deliverables, 60-80% for long-term deliverables. Revisit the schedule and revise your estimates after the Initiation Phase (Kickoff) and again after the Design Phase to improve on these early confidence levels
9. Don’t let yourself be bullied into committing to something you cannot achieve
10. Don’t bully someone else into committing to something they cannot achieve
11. Notify “Need To Know” people AS SOON AS POSSIBLE if there is a significant problem or potential problem in meeting the schedule. Remember that there was a certain degree of optimism in the schedule originally. Note: It's an art to not over-do this
12. Let team members know that you, the project manager, expect early notification of schedule problems as a courtesy. You decide on the severity or risk of the problem and its impact to the schedule, what actions to take, and what contingencies are appropriate
13. Most people’s estimating skills improve with experience; some don’t
14. Learn your own estimating flaws and compensate for them. Then learn the flaws in your new estimations and compensate for them. Repeat continuously while employed as a project manager
15. Learn others' estimating flaws and learn to compensate for them. Mentor them on improving their flaws and then compensate for their improvements. Repeat continuously while they are on your project team
16. In some environments, some people are hedging their estimates, some people are expecting them to hedge the estimates and some people are doing neither. It’s an interesting problem to get all of them to stop this behavior and have people give honest, best-effort estimates. Laws 14 and 15 are useful for dealing with this variability while you are working to get your team members to be more honest with you. Laws 13-16 are part of the "people aspects" of the project management job - like it or not, we have to deal with these "real world effects" on the projects we manage
17. Be wary of anyone who wants 100% confidence in an estimate. 90% confidence is an exceptional human achievement for any complex task, even with extremely good data
18. Look up the word “estimate” in the dictionary. You may find it useful in a meeting