Search This Blog

Monday, October 30, 2006

Project Change Management

I have returned from Seattle, and PMI put on another great global congress. I'm reenergized about my profession and the opportunities available for Project Managers. If you haven't attended a PMI Global Conference I would strongly suggest you try to attend the next one in 2007 in Atlanta, GA.

One of the things I'm trying to focus on this year is doing a better job of managing project change. Remember, project management is really about controlling change. As project managers we need to control change in order to control our project's scope. If we don't do a good job of controlling change our project will get off track quickly.

Develop a good change management process during project initiation, and utilize it throughout your project.

Some other change management tips:

Capture all requests for change in writing

Have a common process for approving or rejecting change requests

Understand what the change(s) will impact

Understand how the change will impact your costs, schedule, scope, and quality

Make sure you have the right people review the change

If changes are approved, ensure you update any baselines that are impacted by the change

Changes in your project are inevitable, but controlling change is the responsibility of the project manager. Are you in control of your project's change?

Friday, October 20, 2006

PMI Global Congress - Seattle


I'm headed to Seattle for the annual PMI Global Congress. I always enjoy this conference because I'm able to see the latest products the vendors have, and always learn a lot from the various presentations.

I have really been busy this week. I'm in the final stages of implementing an Asset/Work Management system for our IT group and the challenges have been a bit overwhelming at times. I long for the days when I had a strong sponsor and some level of commitment from all stakeholders. I work in a very challenging environment where Earned Value and IT Project Management aren't always highly valued.

I have learned in my current environment that results aren't always as important as managing perceptions.

I have always believed as Project Managers we should be judged equally on what I call the PCA Triangle. At the top of the triangle is a "P" for Process. On the bottom right is "C" for Communication, and at the bottom left is "R" for Results. Remember I said we "should" be measured equally in regards to our overall performance.

Some organizations focus mainly on results when evaluating projects and project managers. This is a big mistake. If I manage a project and make everyone mad, don't communicate up, down, and across the organization, but deliver the project on time and on budget did I succeed? What if the scope wasn't properly captured due to poor communications and lack of process? Will people really embrace the project's deliverables? Will they project even be accepted?

Results are important, but the process you use to get the results and the way you communicate along the way are just as important.

Hope to see some of you in Seattle. E-mail me using the following address if you are in Seattle next week and we can meet for coffee - sseay(at)scgov.net

Until next week!

Stephen F. Seay, PMP

Monday, October 09, 2006

Projects, Leaders, and Discipline

One of the things that hurt project teams most is the lack of an enterprise (executive) focus and oversight regarding the management of projects. It takes discipline to manage projects, and enterprise project discipline is lacking when executives are disinterested or disengaged. Great organizations (not project managers) manage projects well, and in doing so they have employees with higher morale, they get better project results, and implement projects faster with higher quality.

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

This has been around for quite some time. I thought it was worth posting here for people that haven't read it. Very profound, very true, very sad. 

The paradox of our time in history is that we have taller buildings but shorter tempers, wider freeways , but narrower viewpoints. We spend more, but have less, we buy more, but enjoy less. We have bigger houses and smaller families, more conveniences, but less time. We have more degrees but less sense, more knowledge, but less judgment, more experts, yet more problems, more medicine, but less wellness. We drink too much, smoke too much, spend too recklessly, laugh too little, drive too fast, get too angry, stay up too late, get up too tired, read too little, watch TV too much, and pray too seldom. We have multiplied our possessions, but reduced our values. We talk too much, love too seldom, and hate too often. We've learned how to make a living, but not a life. We've added years to life not life to years. We've been all the way to the moon and back, but have trouble crossing the street to meet a new neighbor. We conquered outer space but not inner space. We've done larger things, but not better things. We've cleaned up the air, but polluted the soul. We've conquered the atom, but not our prejudice. We write more, but learn less. We plan more, but accomplish less. We've learned to rush, but not to wait. We build more computers to hold more information, to produce morec opies than ever, but we communicate less and less. These are the times of fast foods and slow digestion, big men and small character, steep profits and shallow relationships. These are the days of two incomes but more divorce, fancier houses, but broken homes. These are days of quick trips, disposable diapers, throw away morality, one night stands, overweight bodies, and pills that do everything from cheer, to quiet, to kill. It is a time when there is much in the showroom window and nothing in the stockroom.

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

Monday, August 28, 2006

Important Words

Important Words for the Workplace

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

Friday, August 18, 2006

10 Unbreakable Rules for Project Success

10 Unbreakable Rules for Project Success
Mark Lilly and Tim Rahschulte

Why do so few projects succeed? Despite the decades of increasingly complex attempts to manage projects, far too many managers overlook the 10 Unbreakable Rules for Project Success. As outlined below, these common sense guidelines hold the key to increasing your success rate and delivering greater consistency across your project's lifecycle.

Rule #1: Know what you are doing

Take a deep breath and a half step back. See where it is you wish to go and know what it is you are trying to accomplish. See how it may be coordinated or in conflict with other project efforts across the organization. Focus to the point where you can be deliberate.

Rule #2: Know why you are doing it

Just as it is important to understand what you are doing, it is equally important to understand why you are doing it. This adds perspective and dimension that the project exists for reasons beyond itself. Research has shown that when a project results in deliverables that are designed to meet a thoroughly documented need, then there is a greater likelihood of project success. So managers should insist that there is a documented business need and justification for the project before they agree to consume organizational resources in completing it.

Typically, projects are born from one of two notions: (1) there is an external force such as a market demand or opportunity, or (2) there is an internal force such as operational inefficiencies or manufacturing throughput problems. Either reason requires a project focused work effort. But from a project perspective you need to know why you are doing what you are doing. This has impact on creating metrics, identifying stakeholders, and (possibly most important) creating a comprehensive plan for execution. Is the project necessary? Does it align with the organization's purpose and achieve major goals and objectives for the firm? Can you see the positive change it has on the organization and its customers? If yes, proceed.

Rule #3: Be prudent, honest and prepared

No organization has unlimited time and funds, so be prudent and deliberate with each project task and action. Do not waste people's time for it is precious and expensive and as such should be spent on positive and productive endeavors.

There has not been a single project that has succeeded under the guidance of the dishonest and yours will not be the first. Trust in your team. Be proactively upfront and honest.

Remember Louis Pasteur, "Chance favors only the prepared mind" so forever be prepared. Projects are too dynamic to depend on luck and chance to guide your way. Prepare to fail. Prepare to be surprised? Prepare for the 'what-ifs' you are sure to face throughout the lifecycle of your project. And, prepare to succeed.

Rule #4: Play to your strengths

This rule takes on many themes. But in short, know what you know. This is true when looking at the organizational level and the project level work. How well do you remember your Economics from college? In 1776, Adam Smith argued that trade is a zero sum game in his great work, An Inquiry into the Nature and Causes of Wealth of Nations. Attacking mercantilist assumptions, Smith explained differences in countries based on their abilities to efficiently produce goods, making way for the idea of absolute advantage. This advantage is apparent when a producer of a good is more efficient than any other, thus gaining a superior edge over competitors.

This theory still holds true today and is applicable not only from country to country as Smith argued, but also from organization to organization. The point is, focus on your core competencies and outsource or partner as much as possible with experts who posses a superior advantage.

Rule #5: Know how to navigate

You need a plan and need time to plan. You must be able to envision the final result of the successful project, break that result down into manageable milestones or phases of work and define the critical path to each milestone. This means breaking down the vision of the project into understandable pieces for everyone on the team.

Some enterprises follow a predetermined methodology for all projects. Many enterprises do not. If you do not have a project methodology, know there is no easier way to fail than by just winging it. The next easiest way to fail is to manage every project in a different way. With this approach, you are sure to achieve lackluster performance and retain zero project-based knowledge. Find or create a methodology that works for your organization's business and within your culture, then manage and refine it as you grow.

Your plan needs to break down each work effort, allocate appropriate time for full completion of each task and assign an owner responsible for successfully accomplishing the task. Please note: you, as a project manager, need to understand that individuals responsible for task completion must have the knowledge, skill and tools to achieve their tasks.

Knowing the who, what, when is not confined to only the project team. What about the stakeholders? They have roles and responsibilities too and therefore need coordinating. Whether they are acknowledgers, advisers, critiquers, or vetoers/approvers, you have to coordinate their efforts and make sure they understand what they need to do, why, and when.
Projects are fluid, dynamic, real. Hence, unexpected events are sure to arise and deviate the team from its original plan. These occurrences do not mean the project outcomes are destined to be lived out only in the theories of blue skies. Rather, they are mere occurrences that must be addressed by intelligent people who can navigate precisely through problems and issues.

Rule #6: Know how to communicate

It is imperative to know how to communicate effectively, whether it is written, verbal, visual, body language or the like. It may be better to know that assumptions run wild on project teams; and assumptions foster perceptions; and perceptions create an errant reality. This is what will challenge your communication skills. Since teams are comprised of individuals, all with unique thinking capacities, you must be able to communicate to a diverse group of folks with differing perceptions, beliefs and cares. To best communicate, do so in detail and be colorful. That is, quantify your statements and use examples and stories when possible. And, make sure your statements are based in fact.

To keep the team informed of project work underway and forthcoming events, sponsor regular project meetings and share regular project status reports and/or scorecards. Remember, projects do not always remain on course. To that end, not all communication is favorable. If bad things happen, communicate the bad and reinforce the risk/issue mitigation plan that is in place. Do not shy away from needed any communication, but know when to stop talking and get back to acting upon the information just shared.

Rule #7: Know how to succeed

Projects are meant to succeed. They are meant to make organizations better and customers more satisfied. The first step to satisfying all project stakeholders is to believe you will succeed with the project, and instill that mindset into your team members.
All projects ride on three pillars of strength: people, resources and knowledge. When you have professional personnel, enough time and money, and the right information, quality results ensue from each project engaged. However, if you have too few or too many of these, you will struggle or worse.

Further, projects tied to a key organizational goals or major objective seem to have a greater chance of success. If your project is not tied to an organizational goal, refer to Rule #2 and make sure you understand why you are involved with the project.

A positive attitude is a must. Project leaders and team members must believe a project can succeed or it never will. As well, the organization must be set up to succeed, with every project underway addressing the goals of the firm. As each project succeeds it reinforces the organization's goals and strengthens its chances for success.

Rule #8: Know how to fail

If you want to fail, compromise one of the three pillars described in Rule #7. Trust me, compromising any one of the three will do just fine.

This rule is not meant to be a way out of difficult projects. Again, projects are supposed to succeed. This rule, rather, is here to get you to know what to look for in a failing project and be able to respond quickly with the mitigation plan. Projects fail for many reasons: lack of commitment from senior management; no clear vision; deliverables are not defined; no plan for success let alone quantified risk mitigation; decisions are made based widely on assumptions rather than business data and fact; stakeholders are passively involved; no understanding of a work breakdown structure; and poor communication.

If your project seems to be slipping away, review this list and enact change. Get back on course. Deploy a sense of urgency and strive to succeed! If despite your valiant efforts the project is beyond repair, learn from it. Glean the invaluable knowledge of failure and next time you can avoid these missteps on your way to success.

Rule #9: Know when the project is over

At the end of each phase and at key milestones throughout the project's lifecycle, the project is atop a fulcrum and is poised to continue or not. It is at each of these major points that the project manager and other sponsors need to pay close attention to the metrics and dynamics of the project. Are the goals being met? Has the environment or reasons for the project changed? Can we still succeed? It is at these points these questions must be answered. If all is well, the project goes on. If there are concerns, the project may be better off coming to a brisk halt.

Do not be afraid to stop a project if the reasoning for continuing is no longer sound. It is far better to terminate a project early than to push through to the end with a product or output that satisfies no one and has cost the organization dearly. And, this says nothing about what it does to the project team's psyche. If it is not going to work, kill it. Your time and money are better spent on some greater cause.

Rule #10: Know how to learn

Your project is not a success unless you can learn and share your knowledge with others for the organization at large to grow. Learning is constant. It is an asset to be leveraged and a sustainable differentiation for the modern day organization. It is undoubtedly true, knowledge is power. The only means in which knowledge is derived is through the process of learning. Learn to create knowledge. Leverage knowledge into power.

The success achieved from project management is more than simply enacting a methodology standard or carrying out a set of template-driven exercises. Success, rather, is achieved through the intelligent application of sound principles guided by experienced project professionals. If this sounds like common business sense, it is. As measured, all successful projects have similar attributes for us all to learn from.

These are the unbreakable rules of project management.

ProjectSteps Note: I found the above document in my Project Management Library of Whitepapers and found it made some great points. Do you maintain a personal library of Whitepapers, Website links, etc? You should. Of course, a Project Management library does you no good if you don't reference it on a regular basis.

Monday, August 14, 2006

PMI World Congress - North America

Anybody out there going to the PMI Global Congress in Seattle? If so, how about if we meet up at the reception below? Never too early to plan.

You are invited to a private reception …

PMI and its co-sponsor the International Institute for Learning, invite you to a networking reception exclusively for Project Management Professionals (PMP®) while attending PMI Global Congress 2006—North America.

Sunday, 22 October 2006
7:30-9:00 p.m.
Room 6-A
Hors d'oeuvres and beverages will be served

At this reception you have an exclusive opportunity to network with your PMP colleagues, share project successes and discuss the next big project… In addition to the opportunity to attend this reception, the North America Congress offers you over 80 educational sessions to get the most up-to-date project management areas of focus.

Make plans to attend the PMP Reception, find out more about other congress events, register to attend and mark October 22 on your calendar.

See you in Seattle!

Thursday, August 10, 2006

The 4 Disciplines of Execution - Part 4

I have edited the last 3 postings on this topic because I noticed that while I described everything about the Disciplines, I never listed the Disciplines themselves. Sorry for the confusion. Like I said, I updated the prior postings, and have listed the 4 Disciplines below.

They are:

1 - Focus on the Wildy Important

2 - Create a Compelling Scorecard

3 - Translate Lofty Goals into Specific Actions

4 - Hold Each Other Accountable - All of the Time

-----------------------------------------------------------

Discipline 4 - Hold Each Other Accountable - All of the Time

"Knowing others are counting on you raises your level of committment"

Maintaining commitment to the goal requires frequent team accountability. Traditional Staff meetings won't suffice. You need a better process for engaging the team and reporting on results - the WIG Session.

Key Things to Remember

* Wildly important goals - focus is on WIGs, real work gets done, team focused.
* Triage reporting - quick reporting, socre board reviewed, follow-through, successes celebrated.

* Finding Third Alternatives - problem solving, 1+1=3, wisdom of group.

* Clearing the path - a stroke of the pen for me, "A+" behavior, asking for help.

Click here to read a short article about the 4 Disciplines of Execution wrtiten by Stephen Covey

Friday, August 04, 2006

4 Disciplines of Execution - Part 3

This week's entry is a continuation of my previous posting regarding what Dr. Stephen Covey calls the "4 Disciplines of Execution". This text is taken directly from FranklinCovey's "The 4 Disciplines of Execution Quick Reference".

"To achieve goals you've never achieved before, you need to start doing things you've never done before"

Discipline 3 - Translate Lofty Goals into Specific Actions

It's one thing to come up with a new goal or strategy. It's quite another to actually put that goal into action, to break it down into new behaviors and activities at the front line.

Key Things to Remember

* Think new and better. Often, we expect different outcomes while continuing to do the same things. New results often require a creative new behavior. Identify new or better behaviors by replicating pockets of excellence (what's being done superbly well already) or by creating them from imagination.

* Plan weekly. Break down your team's top goals into weekly bite-size chunks. As you plan your week ask yourself, "What are three most important objectives I must accomplish this week to move the team's goals forward?"

* Plug into your planning system. Schedule into your planning system the vital few things you must accomplish each week.

Knowing and doing are two different things.

______________________________________________________
Makes sense to me. I have always like the old project management saying, "What is not is writing has not been said". Maybe we should change that to, "What is not in writing doesn't get done".

Any comments?

Thursday, July 27, 2006

4 Disciplines of Execution - continued

This week's entry is a continuation of my previous posting regarding what Dr. Stephen Covey calls the "4 Disciplines of Execution". This text is taken directly from FranklinCovey's "The 4 Disciplines of Execution Quick Reference".

Discipline 2 - Create a Compelling Scorecard

Measures and a scoreboard ensure that people have the same understanding of goals. Turn your measures into a compelling scoreboard that is accessible, visual, engaging, doable, and concise.

Key Things to Remember

Types of Measures

* Lagging - provide an historical look at past performance

* Leading - provide measures that are predictive of future results.

* Real-time - show where things are right now. They allow corrective action to be taken immediately to affect the outcome.

Measurement Credibility Checklist

* Accurately tracks progress toward the goal

* Inputs cannot be easily manipulated

* Can be influenced by the team

* Drives the right behaviors

* Tracks outcomes as well as activities

* Is truly achievable

* Has no unintended consequences

* Value of measuring exceeds cost of measuring

For more information on the "4 Disciplines of Execution", click here.

Thursday, July 06, 2006

The 4 Disciplines of Execution

Dr. Stephen Covey is one of my favorite authors. His books, writing, lectures, and course offerings are well worth reviewing. As I was looking through my bookshelf I came across a CD and short brochure around what Dr. Covey calls the 4 Disciplines of Execution.

Over the next few weeks I will go through each Discipline. Today, I will talk about Discipline 1.

As taken from the "4 Disciplines of Execution" brochure:

Discipline 1 - Focus on the Wildly Important

To achieve results with excellence, you must focus on a few wildly important goals and set aside the merely important. Choose to do a few things with excellence rather than many things with mediocrity.

Key Things to Remember

Too many goals, conflicting or not, lead to confusion, burnout, decline in quality, and loss of focus".

Align your goals with those of your organization as well as the key teams you work with".

Use the Importance Screen (reference to CD) to help identify your wildly important goals

Click here to view Importance Screen

Create Sell-Crafted Goals

* Specific and clear

* Explicitly linked to corporate strategy

* Plain language

* Bite-size chunks

* measurable

* Deadline-driven

For more information click here to go to Franklin Covey's website.

Tuesday, June 27, 2006

New PMI Standards

The Project Management Institute has released two new standards. They are:

The Standard for Program Management

The Standard for Portfolio Management


As stated in the Standard for Program Management, "The Standard for Program Management aims to provide a detailed understanding of program management and promote efficient and effective communication and coordination among various groups. With its ability to help assess the variety of factors linking projects under one program and provide the best allotment of resources between those projects, this standard is an invaluable tool for program and project managers alike."

In the introduction the Program Management Standard states: "The Standard for Program Management provides guidelines for managing programs within and organization. It defines program management and related concepts, describes the program management life cycle and outlines related processes. This standard is an expansion of information provided in A Guide to the Project Management Body of Knowledge."

It appears on first glance that both Standards will be an excellent resource for all project managers. You can purchase them both at the PMI website

Your comments are always welcome

Wednesday, June 21, 2006

Vacation is Over, but what a Ride!

Some photos from my vacation are included below. I rode the Harley to Cartersville, GA, Fontana Dam, NC, up and around the Blue Ridge Parkway, on to Asheville, NC, then back home. The weather was great, the scenery incredible, and the break from work much needed. Hopefully the photos will tell part of the story.

Mountain View



Flowers in the Mountains



Devils Courthouse - Blue Ridge Parkway



Another View



Motorcycle Project Dude

Thursday, June 08, 2006

Vacations are Projects Too!



Well I'm off for vacation on Saturday. I'm riding my Harley-Davidson to Atlanta and staying for a couple of days with a friend, then moving on to the Road King Riders Rendevouz in Fontana, NC. After a couple of days of riding in the Smokey Mountains I will ride to Asheville, NC for my sister-in-laws wedding.

In order to make sure the trip is as uneventful as possible, I have created a checklist of things to do and take, as well as pre-planning my route. Additionally, as part of the pre-trip process I have completed a maintenance and safety check on the motorcycle, and ensured I have my insurance, registration, and other paperwork required for the trip.

While taking the time to plan the trip won't guarentee success, it should reduce the chances of problems while on the road.

What out for Motorcyles, they are Everywhere! Posted by Picasa

Monday, June 05, 2006

Quotes from Tom Peters

As many of you know I'm a big fan of Tom Peters. I own a couple of his books, and I like to review materials on his website from time to time. Below you will find several quotes and bits of wisdom that I have gleamed from Tom's writings. Hopefully you will enjoy them as much as I have.

In any public-sector business, you must become an avid student of "the politics," the incentives and constraints, mostly non-economic, facing all of the players. Politicians are usually incredibly logical if you (deeply!) understand the matrix in which they exist.

Risk Assessment & Risk Management is more about stories than advanced math i.e., brilliant scenario construction.

Don't waste your time on jerks, it'll rarely work out in the mid- to long-term.

Under promise (i.e., don't over-promise; i.e., cut yourself a little slack) even if it costs you business; winning is a long-term affair. Over-promising is Sign #1 of a lack of integrity. You will pay the piper.

There is such a thing as a "good loss", if you have tested something new and developed good relationships. A half-dozen honorable, ingenious losses over a two-year period can pave the way for a Big Victory in a New Space in year 3.

Keep it simple! (Damn it!) No matter how "sophisticated" the product. If you can't explain it in a phrase, a page, or to your 14-year-old ... you haven't got it right yet.

Don't hold grudges. (It is the ultimate in small mindedness, and incredibly wasteful and ineffective. There is always tomorrow.)

Little People often have Big Friends!

Work hard beats work smart. (Mostly)

Phones beat email.

Obsess on ROIR (Return On Investment In Relationships).

Scoring off other people is stupid. Winners are always in the business of creating the maximum # of winners among adversaries at least as much as among partners.

Your colleagues' successes are your successes. Period.

Lend a helping hand, especially when you don't have the time.

Don't get too hung up on "systems integration", first & foremost, the individual bits have got to work.

For Gods sake don't over promise on systems integration it's nigh on impossible to deliver.

It's Relationships, Stupid; Deep and from multiple functions.

Don't over-schedule. Running late is inexcusable at any level of seniority; it is the ultimate mark of self-importance mixed with contempt.

"Preparing the soil" is the first 98 percent. (Or more.)

Be kind. It works.

Opportunism (with a little forethought) mostly wins.

"Reward excellent failures. Punish mediocre successes."

Integrity. Credibility. Humanity. Grace.

Strategic planning is the last refuge of scoundrels

Focus groups are counter-productive

All information making it to the top is filtered to the point of danger and hilarity

"Success stories are the illusions of egomaniacs (and "gurus")

If you believe the "cause & effect" memoirs of CEOs, you should be institutionalized

"Top teams" are "Dittoheads"

"Expert" prediction is rarely better than rolling the dice

Statistically, CEOs have little effect on performance

Success kills

Tuesday, May 30, 2006

The Water is Full of Sharks

In the past, I enjoyed reading the book, "Power and Politics in Project Management" by Jeffrey K. Pinto (and still review it periodically). One section of the book has had special significance for me of late. I have to admit that I'm not a very good politician. I have learned over the years that playing politics is a skill set I need to work on. As mentioned in the book, we need to be aware of all political behaviors (Naive, Sensible, and Shark) and react to them appropriately if we are to keep ourselves from getting in to trouble.

One behavior I have had the unfortunate experience of witnessing lately is that of the Political Shark. These types of people have certain character traits that if not recognized can negatively impact our careers. These sharks know how to play the self-serving political "game" and don't mind leaving blood in the water. They are experts at manipulating the system to get their way and have no interest in serving anything but their own desires. They have loyalty only to themselves and their own goals.

SHARKS ARE PREDATORS, AND ARE INDISCRIMINATE WHEN FEEDING!

To quote from the book, "work with them (sharks), and one is likely to be used and manipulated; get between them and their goal and their behavior becomes utterly amoral." "The only cause these individuals espouse is their own."

The author goes on to make an important point; Sharks "enter organizations with the express purpose of using politics and aggressive manipulation to reach the top."

As summarized in the book, Sharks are:

* Opportunistic

* Self-serving and predatory

* Manipulators that will use fraud and deceit when necessary

* Bullies that will misuse information and use others to service their own means

Do you know or work with or for a shark? What can a project manager do to ensure these types of individuals don't negatively impact their projects?

Here are some things to keep in mind:

* Be aware that sharks exist in your organization

* Know who the sharks are and avoid them whenever possible

* When working with sharks, be very careful not to become their prey

* Learn to be politically "Sensible"

* Be a good negotiator

* Expand your network and be fair and honest in all of your dealings

* Be comforted in the fact that Sharks will eventually move on to new feeding grounds

It is unfortunate that political sharks are so prevalent in organizations. They offer little value to the organization other than to serve their own means. Occasionally sharks do good things, but the cost of their behavior will always be a disruption to the organization. The benefit is rarely worth the cost.

Don't trust a shark. Don't turn your back on them and don't take them lightly. Remember they are self-serving and will stop at nothing to satisfy their appetite. I have seen the damage they can do first hand and I know they are indiscriminate in the way the feed. Even though we have to swim with the sharks, we don't have to become their victims.

Keep your friends close, but the sharks closer.

Monday, May 22, 2006

Project Challenges

I just received the latest addition to my project management library. The book, The Wiley Guide to Managing Projects is big (over 1400 pages), comprehensive, expensive, and has more information than I could absorb in a lifetime. While I wouldn't recommend the book for everyone, I would say that it covers just about every aspect of project management in enough detail to make it a book you should consider having on your desk.

I have been very busy with a large enterprise project that has been a real challenge. As project managers we have all been in the same boat regarding managing projects that have taken on a life of their own. We have the knowledge, experience, and lessons learned from past projects to manage these projects effectively, yet our current project(s) aren't going as planned. Are you managing "change"?

Project change and the associated problems/opportunities they create are all part of the project management game. Changes to project scope can improve project results, however it helps if we can anticipate these changes so we can manage them more effectively.

Project change requires that we communicate and anticipate. Failure to manage change can result in project failure and cost overruns. Additionally, relationships can be damaged and careers ruined. Needless to say, these things happen to project managers everyday.

So what do we do when faced with the big project challenges? My advice is to keep plugging away and rely on your experience, knowledge, perseverance, and project management fundamentals to get your projects back on track.

Any war stories you have can be added to the comments section.

Thanks,

Stephen F. Seay, PMP

Keep fighting the good fight.

Monday, May 08, 2006

Good Project Management Websites

The list of useful Project Management links was found on the forums over at http://forums.pmforum.org/

REPOST - Cleaned up Links and Formatting

The new eProject eLounge (A great source of blogs, forums, download, and other info)
http://elounge.eproject.com/

100 Rules for Project Managers (Some great gems of project management wisdom from NASA's Goddard Space Flight Center.)

http://www.altisinc.com/Links/100_Rules.html

12Manage – Management method, models and theories
http://www.12manage.com/

4PM – Free project management knowledge library
http://www.4pm.com/

AllPM - Project Manager's Resource Center
http://www.allpm.com/

ASAPM (American Society for the Advancement of Project Management)
http://asapm.org/

CapacityPlanning.Com
http://www.capacityplanning.com/

CIO Magazine (Good information for a variety of subjects including project management.)
http://www.cio.com/

CM Today - Configuration Management News
http://www.cmtoday.com/

Cutter IT Journal
http://www.cutter.com/itjournal/

Defense Acquisition University 4 PMs
http://www.dau.mil/pubs/pmtoc.asp

Earned Value Management
http://www.acq.osd.mil/pm/

Effective Meetings
http://www.effectivemeetings.com/

e-Programme - Portfolio Management Web Site
http://www.e-programme.com/

GanttHead - Developed for PMs by PMs
http://www.gantthead.com/

HrGopher - Good HR information for everyone
http://www.hrgopher.com/

Information Systems Specific Interest Group (PMI)
http://www.pmi-issig.org/

IT-Director.Com, information for the IT Director
http://www.it-director.com/

itmWEB, IT Management information
http://www.itmweb.com/

ITtoolKit for Managing Technology, PM Toolkits and information
http://www.ittoolkit.com/index.shtml

The wisdom of Max Wideman
http://www.maxwideman.com/

Methodology.Org
http://www.methodology.org/

MIT's Project Management Resources
http://web.mit.edu/pm/

NewGrange - Center for Project Management
http://www.newgrange.org/

PM Boulevard
http://www.pmboulevard.com/home.jsp

PMI (Project Management Institute)
http://www.pmi.org/

Portfolio Management Forum
http://www.portfoliomgt.org/

PowerPointers - Creating Effective Presentations
http://www.powerpointers.com/

Product Development & Management Association
http://www.pdma.org/

Project Development Disciplines from Paul Allen
http://members.aol.com/AllenWeb/index.htm

ProjectHero - Real World War Stories
http://www.projecthero.com/

Project Magazine - Free Online Resource
http://www.projectmagazine.com/

Project Management Forum
http://www.pmforum.org/

Project Management W3 Site
http://www.projectmanagement.com/

Project Manager Today
http://www.projectnet.com/

Project Smart Resource Centre
http://www.projectsmart.fsnet.co.uk/

Projects @ Work Magazine
http://www.projectsatwork.com/

Service Level Management
http://www.nextslm.org/

The Software Engineering Laboratory (NASA)
http://sel.gsfc.nasa.gov/website/index.htm

Software Program Manager's Network
http://www.spmn.com/

Software Project Management Sites
http://huxley.baz.com/kjordan/swse625/sites.html

SoftwareDioxide - Ecosystem 4 Software
http://www.softwaredioxide.com/

StickyMinds - Resource 4 Building Better Software
http://www.stickyminds.com/

TechGuide - Practical Guidance for IT Pros (BNET)
http://www.techguide.com/

University of Washington Project Management Guidelines
http://www.washington.edu/computing/pm/

Virtual Project Management & Teams
http://www.vrtprj.com/

Workaholic International Network
http://www.workaholic.org/

Software Projects Org
http://www.softwareprojects.org/

IPMA (International PM Association)
http://www.ipma.ch/

Wednesday, May 03, 2006

In Project Management, Criticism is Inevitable

Criticism is something we can avoid easily by saying nothing, doing nothing, and being nothing. Aristotle, Greek philosopher and scientist

Many of you probably know that every now and then I can be critical of a situation or type of person. Evidence of this fact can be seen in last week's posting or others regarding teams, executive apathy, etc. One thing we can all learn about criticism from others - "if you expect criticism, you will seldom be disappointed when you receive it" - Author unknown.

We know that not all criticism is constructive. Many types of criticism are destructive and that is what I want to talk about. Destructive criticism is something you receive that offers virtually no value, and comes from people that don't have your best interests at heart. Sometimes the criticism may have some merit, however when speaking about destructive criticism, the presentation wasn't communicated effectively or was only meant to do harm.

Remember, criticism is just an opinion, but if offered constructively it may be valid and helpful.

Keep an open mind when being criticized. Don't let the criticism control you or change what you think about yourself. Ask yourself, can I learn anything from the criticism? Can I change anything? Should I change?

I don't take criticism well, and I tend to discount those people around me that criticize others too much. I need to take my own advice and learn to be more accepting of criticism, especially when it is constructive.

Some rules we should follow regarding criticism:

Never criticize another behind their back. Keep in mind what Stephen Covey says and have "respect for the absent".

If there is nothing to be learned when you are criticized it is best to ignore it and move on with your life.

Responding to criticism that has no value will only reduce you to the level of the person doing the criticizing.

Don't let deceivers deceive YOU!

Monday, April 24, 2006

E-mail + Blackberrys = Frustration

Have you ever been in a meeting and watched people take their attention from what is being discussed to respond to a message on their Blackberry ? Does anybody else find this to be distracting and just plain rude? Are the people using Blackberrys and the messages they receive so important that they must take their attention away from you or others to respond instantly to their e-mail? I think not. These users will claim that they are listening to you and paying attention; however, that has proven not to be the case.

The overwhelming majority (99%) of people can't read and effectively listen simultaneously. The ones that say they can are the ones you need to worry about. They aren’t listening and that can hurt your project.

A recent research report out of King's College, London, claims that e-mail use has addictive aspects and that it causes a temporary IQ drop of up to 10 points-—a bigger drop than that caused by inveterate pot-smoking! Add to the e-mail mix an addictive, on-the-hip, always on device like a Blackberry, and this lapse in intelligence can affect meetings, projects, and your ability to effectively do your job.

Some Blackberry users I know are addicts. Just like a smoker, when the urge strikes out comes the Blackberry. They don't see the harm. They are being productive, responsive, accountable, saving time, money, etc... In meetings or conversations they are a distraction, an annoyance, and not giving you and others their full attention. They are out of touch and oblivious to what is important.

You have seen the scenario; whenever the device buzzes, chirps, or rings everything around them ceases to be important except the message on their device. They must respond and must respond now. Is this behavior acceptable now? If we were having a conversation and you picked up a book and started reading, or turned on a nearby television and started watching and changing channels wouldn't that be a sign that what I was saying wasn't important?

Hopefully one person (besides me) will read this message and change their behavior. When I see senior management or leaders exhibit this type of behavior it makes me wonder how they would feel if I exhibited this behavior when they were talking.

Turn off the Blackberry during meetings or leave them at your desk. . You aren’t that important and neither are the messages you are reading!

End of rant...

Comments welcome

Tuesday, April 18, 2006

Leadership Lessons from General Colin Powell - Last in Series

Lesson 13

"Powell's Rules for Picking People:” Look for intelligence and judgment, and most critically, a capacity to anticipate, to see around corners. Also look for loyalty, integrity, a high energy drive, a balanced ego, and the drive to get things done.

How often do our recruitment and hiring processes tap into these attributes? More often than not, we ignore them in favor of length of resume, degrees and prior titles. A string of job descriptions a recruit held yesterday seem to be more important than who one is today, what they can contribute tomorrow, or
how well their values mesh with those of the organization. You can train a bright, willing novice in the fundamentals of your business fairly readily, but it's a lot harder to train someone to have integrity, judgment, energy, balance, and the drive to get things done. Good leaders stack the deck in their favor
right in the recruitment phase.

Lesson 14

"Great leaders are almost always great simplifiers, who can cut through argument, debate and doubt,
to offer a solution everybody can understand."


Effective leaders understand the KISS principle, Keep It Simple, Stupid. They articulate vivid, over-arching goals and values, which they use to drive daily behaviors and choices among competing alternatives. Their visions and priorities are lean and compelling, not cluttered and buzzword-laden. Their decisions are crisp and clear, not tentative and ambiguous. They convey an unwavering firmness and consistency in their actions, aligned with the picture of the future they paint. The result: clarity of purpose, credibility of leadership, and integrity in organization.

Lesson 15

Part I: "Use the formula P=40 to 70, in which P stands for the probability of success and the numbers indicate the percentage of information acquired.” Part II: "Once the information is in the 40 to 70 range, go with your gut."

Don't take action if you have only enough information to give you less than a 40 percent chance of being right, but don't wait until you have enough facts to be 100 percent sure, because by then it is almost always too late. Today, excessive delays in the name of information-gathering breeds "analysis paralysis." Procrastination in the name of reducing risk actually increases risk.

Lesson 16

"The commander in the field is always right and the rear echelon is wrong, unless proved otherwise."

Too often, the reverse defines corporate culture. This is one of the main reasons why leaders like Ken Iverson of Nucor Steel, Percy Barnevik of Asea Brown Boveri, and Richard Branson of Virgin have kept their corporate staffs to a bare-bones minimum - how about fewer than 100 central corporate staffers for global $30 billion-plus ABB? Or around 25 and 3 for multi-billion Nucor and Virgin, respectively? Shift the power and the financial accountability to the folks who are bringing in the beans, not the ones who are counting
or analyzing them.

Lesson 17

"Have fun in your command. Don't always run at a breakneck pace. Take leave when you've earned it:
Spend time with your families. Corollary: surround yourself with people who take their work seriously, but not themselves, those who work hard and play hard."


Herb Kelleher of Southwest Air and Anita Roddick of The Body Shop would agree: seek people who have some balance in their lives, who are fun to hang out with, who like to laugh (at themselves, too) and who have some non-job priorities which they approach with the same passion that they do their work. Spare me the grim workaholic or the pompous pretentious "professional;” I'll help them find jobs with my competitor.

Lesson 18

"Command is lonely."

Harry Truman was right. Whether you're a CEO or the temporary head of a project team, the buck stops here. You can encourage participative management and bottom-up employee involvement, but ultimately the
essence of leadership is the willingness to make the tough, unambiguous choices that will have an impact on the fate of the organization. I've seen too many non-leaders flinch from this responsibility. Even as you create an informal, open, collaborative corporate culture, prepare to be lonely.

“Leadership is the art of accomplishing more than the science of management says is possible.”

Tuesday, April 11, 2006

Leadership Lessons from General Colin Powell Continued...

Lesson 7

"Keep looking below surface appearances. Don't shrink from doing so (just) because you
might not like what you find."

"If it ain't broke, don't fix it" is the slogan of the complacent, the arrogant or the scared. It's an excuse for inaction, a call to non-arms. It's a mind-set that assumes (or hopes) that today's realities will continue tomorrow in a tidy, linear and predictable fashion. Pure fantasy. In this sort of culture, you won't find
people who pro-actively take steps to solve problems as they emerge. Here's a little tip: don't invest in these companies.

Lesson 8

"Organization doesn't really accomplish anything. Plans don't accomplish anything, either. Theories of management don't much matter. Endeavors succeed or fail because of the people involved. Only by attracting the best people will you accomplish great deeds."

In a brain-based economy, your best assets are people. We've heard this expression so often that it's become trite. But how many leaders really "walk the talk" with this stuff? Too often, people are assumed to be empty chess pieces to be moved around by grand viziers, which may explain why so many top managers immerse their calendar time in deal making, restructuring and the latest management fad. How many immerse themselves in the goal of creating an environment where the best, the brightest, the most creative are
attracted, retained and, most importantly, unleashed?

Lesson 9

"Organization charts and fancy titles count for next to nothing."

Organization charts are frozen, anachronistic photos in a work place that ought
to be as dynamic as the external environment around you. If people really
followed organization charts, companies would collapse. In well-run
organizations, titles are also pretty meaningless. At best, they advertise
some authority, an official status conferring the ability to give orders and
induce obedience. But titles mean little in terms of real power, which is the
capacity to influence and inspire. Have you ever noticed that people will
personally commit to certain individuals who on paper (or on the organization
chart) possess little authority, but instead possess pizzazz, drive, expertise,
and genuine caring for teammates and products? On the flip side, non-leaders
in management may be formally anointed with all the perks and frills
associated with high positions, but they have little influence on others, apart
from their ability to extract minimal compliance to minimal standards.

Lesson 10

"Never let your ego get so close to your position that when your position goes, your ego goes with it."

Too often, change is stifled by people who cling to familiar turfs and job descriptions. One reason that even large organizations wither is that managers won't challenge old, comfortable ways of doing things. But
real leaders understand that, nowadays, every one of our jobs is becoming obsolete. The proper response is to obsolete our activities before someone else does. Effective leaders create a climate where people’s worth is determined by their willingness to learn new skills and grab new responsibilities, thus perpetually reinventing their jobs. The most important question in performance evaluation becomes not, "How well did you perform your job since the last time we met?" but, "How much did you change it?"

Lesson 11

"Fit no stereotypes. Don't chase the latest management fads. The situation dictates which approach best
accomplishes the team's mission."

Flitting from fad to fad creates team confusion, reduces the leader's credibility, and drains organizational coffers. Blindly following a particular fad generates rigidity in thought and action. Sometimes speed to market is more important than total quality. Sometimes an unapologetic directive is more appropriate
than participatory discussion. Some situations require the leader to hover closely; others require long, loose leashes. Leaders honor their core values, but they are flexible in how they execute them. They understand that management techniques are not magic mantras but simply tools to be reached for at the right times.

Lesson 12

"Perpetual optimism is a force multiplier."

The ripple effect of a leader's enthusiasm and optimism is awesome. So is the impact of cynicism and pessimism. Leaders who whine and blame engender those same behaviors among their colleagues. I am not talking about stoically accepting organizational stupidity and performance incompetence with a "what,
me worry?" smile. I am talking about a gung-ho attitude that says "we can change things here, we can achieve awesome goals, we can be the best." Spare me the grim litany of the "realist," give me the unrealistic aspirations of the optimist any day.

Next time I will publish the last of General Powell's Leadership Lessons

Monday, April 03, 2006

More Leadership Lessons from General Colin Powell

All the lessons below were taken taken from a presentation by General Colin Powell. I will publish more of them here in the coming days and weeks.

Lesson 4

"Don't be afraid to challenge the pros, even in their own backyard."

Learn from the pros, observe them, seek them out as mentors and partners. But remember that even the pros may have leveled out in terms of their learning and skills. Sometimes even the pros can become complacent and lazy. Leadership does not emerge from blind obedience to anyone. Xerox's Barry Rand was right on target when he warned his people that if you have a yes-man working for you, one of you is redundant. Good leadership encourages everyone's evolution.

Lesson 5

"Never neglect details. When everyone's mind is dulled or distracted the leader must be doubly vigilant."

Strategy equals execution. All the great ideas and visions in the world are worthless if they can't be implemented rapidly and efficiently. Good leaders delegate and empower others liberally, but they pay attention to details, every day. (Think about supreme athletic coaches like Jimmy Johnson, Pat Riley
and Tony La Russa). Bad ones, even those who fancy themselves as progressive "visionaries," think they're somehow "above" operational details. Paradoxically, good leaders understand something else: an obsessive routine in carrying out the details begets conformity and complacency, which in turn dulls everyone's mind. That is why even as they pay attention to details, they continually encourage people to challenge the process. They implicitly understand the sentiment of CEO leaders like Quad Graphic's Harry Quadracchi, Oticon's Lars Kolind and the late Bill McGowan of MCI, who all independently asserted that the Job of a leader is not to be the chief organizer, but the chief dis-organizer.

Lesson 6

"You don't know what you can get away with until you try."

You know the expression, "it's easier to get forgiveness than permission." Well, it's true. Good leaders don't wait for official blessing to try things out. They're prudent, not reckless. But they also realize a fact of life in most organizations: if you ask enough people for permission, you'll inevitably come up against
someone who believes his job is to say "no." So the moral is, don't ask. Less effective middle managers endorsed the sentiment, "If I haven't explicitly been told 'yes,' I can't do it," whereas the good ones believed, "If I haven't explicitly been told 'no,' I can." There's a world of difference between these two points
of view.

Thursday, March 30, 2006

Leadership Lessons from General Colin Powell

All the lessons below were taken taken from a presentation by General Colin Powell. I like them all, and will publish them here over the coming days.

Lesson 1

"Being responsible sometimes means pissing people off."

Good leadership involves responsibility to the welfare of the group, which means that some people will get angry at your actions and decisions. It's inevitable, if you're honorable. Trying to get everyone to like you is a sign of mediocrity: you'll avoid the tough decisions, you'll avoid confronting the people who need to be confronted, and you'll avoid offering differential rewards based on differential performance because some people might get upset.

Ironically, by procrastinating on the difficult choices, by trying not to get anyone mad, and by treating everyone equally "nicely" regardless of their contributions, you'll simply ensure that the only people you'll wind up angering are the most creative and productive people in the organization.

Lesson 2

"The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help them or concluded that you do not care. Either case is a failure of leadership."


If this were a litmus test, the majority of CEOs would fail. One, they build so many barriers to upward communication that the very idea of someone lower in the hierarchy looking up to the leader for help is ludicrous. Two, the corporate culture they foster often defines asking for help as weakness or failure, so people cover up their gaps, and the organization suffers accordingly. Real leaders make themselves accessible and available. They show concern for the efforts and challenges faced by underlings, even as they demand high standards. Accordingly, they are more likely to create an environment where problem analysis replaces blame.

Lesson 3

"Don't be buffaloed by experts and elites. Experts often possess more data than judgment. Elites can become so inbred that they produce hemophiliacs who bleed to death as soon as they are nicked by the real world."

Small companies and start-ups don't have the time for analytically detached experts. They don't have the money to subsidize lofty elites, either. The president answers the phone and drives the truck when necessary; everyone on the payroll visibly produces and contributes to bottom-line results or they're history. But as companies get bigger, they often forget who "brought them to the dance": things like all-hands involvement, egalitarianism, informality, market intimacy, daring, risk, speed, agility. Policies that emanate from ivory towers often have an adverse impact on the people out in the field who are fighting the wars or bringing in the revenues. Real leaders are vigilant, and combative, in the face of these trends.

Monday, March 27, 2006

Project Managment Culture

Moving your organization to embrace a “project management culture” takes time and patience. A great first step an organization can take is to ensure that their project leaders are trained and fluent in the discipline of Project Management. Also, and most importantly, senior management must understand and embrace the value of project management, and commit to support the process of implementing project management throughout all levels of the organization.

To help change the organizational culture to one that embraces and values project management, it should fund and support the development of a project office, which can help facilitate rolling out this “project management culture”.

Some first steps that should be taken:
  • Clearly define the roles and responsibilities of existing project managers and project support personnel
  • Develop a basic project management training plan for the entire organization to familiarize all with the project management verbiage and practices
  • Identify and provide specialized advanced training for all project leaders and functional managers
  • Develop a project management office (PMO) to provide enterprise coaching, and to develop and manage your organization’s project management methodology
  • In addition to the methodology, the PMO should develop and maintain standard project management templates for the organization to use
  • Ensure that existing projects are audited and meet your organization’s minimum project management standards
  • Setup a program where your PMO provides coaching to less experienced project managers and oversight of all enterprise projects
  • Ensure all projects have Lessons Learned captured
There are many more things that can be added to the list above, but the intent of this posting was to get people thinking about ways to change the Project Management Culture where they work.

To learn more, you can review the book entitled “Advanced Project Portfolio Management and the PMO” on Amazon.com. There is a link to purchase the book on the left hand side of the blog.

Until next time…

Thursday, March 23, 2006

Twenty Good Life Tips

Give people more than they expect and do it cheerfully.

Marry a man/woman you love to talk to. As you get older, their conversational skills will be as important as any other.

Do not believe all you hear, spend all you have or sleep all you want.

When you say, "I love you", mean it.

When you say, "I'm sorry", look the person in the eye.

Be engaged at least six months before you get married.

Believe in love at first sight.

Never laugh at anyone's dreams. People who do not have dreams do not have much.

Love deeply and passionately. You might get hurt but it is the only way to live life completely.

In disagreements, fight fairly. No name-calling.

Do not judge people by their relatives.

Talk slowly but think quickly.

When someone asks you a question you do not want to answer, smile and ask, "Why do you want to know?"

Remember that great love and great achievements involve great risk.

Say, "Bless You" when you hear someone sneeze.

When you lose, do not lose the lesson.

Remember the three R's: Respect for self; Respect for others; Responsibility for all your actions.

Do not let a little dispute injure a great friendship.

When you realize you have made a mistake, take immediate steps to correct it.

Smile when picking up the phone. The caller will hear it in your voice.

Spend some time alone.

Tuesday, March 21, 2006

Does Your Project Still 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, March 13, 2006

More Project Management Sayings

It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women (although it is more fun trying).

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.

Any project can be estimated accurately (once it's completed).

The most valuable and least used WORD in a project manager's vocabulary is "NO".

The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".

Nothing is impossible for the person who doesn't have to do it.

You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
At the heart of every large project is a small project trying to get out.

If you don't stand for something, you'll fall for anything.

The more desperate the situation the more optimistic the situatee.

If it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck.

Too few people on a project can't solve the problems - too many create more problems than they solve.

A problem shared is a buck passed.

A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.

A user will tell you anything you ask about, but nothing more.

A user is somebody who tells you what they want the day you give them what they asked for.

Of several possible interpretations of a communication, the least convenient is the correct one.

What you don't know hurts you.

The conditions attached to a promise are forgotten, only the promise is remembered.

There's never enough time to do it right first time but there's always enough time to go back and do it again.

The bitterness of poor quality last long after the sweetness of making a date is forgotten.

I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant.

Estimators do it in groups - bottom up and top down.

If you're 6 months late on a milestone due next week but really believe you can make it, you're a project manager.

No project has ever finished on time, within budget, to requirement - yours won't be the first to.

Activity is not achievement.

The first myth of management is that it exists.

Managing IT people is like herding cats.

If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it.

A minute saved at the start is just as effective as one saved at the end.

People under pressure do not think faster.

If an IT project works the first time, it is wrong.

If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!

Planning without action is futile, action without planning is fatal.

The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

Planning is an unnatural process, doing something is much more fun.

The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

Projects happen in two ways: a) Planned and then executed or b) Executed, stopped, planned and then executed.

It's not the hours that count, it's what you do in those hours.

Good control reveals problems early - which only means you'll have longer to worry about them.

If there is anything to do, do it!

If it can go wrong it will - Murphy's law.

If it can't possibly go wrong, it will - O'Malley's corollary to Murphy's law.

It will go wrong in the worst possible way - Sod's law.

Work expands to fill the time available for its completion - Parkinson's law.

Finely chopped cabbage in mayonnaise - Coleslaw.

A two year project will take three years, a three year project will never finish - (anyone know who's law this is?)

Murphy, O'Malley, Sod and Parkinson are alive and well - and working on your project.

Tuesday, March 07, 2006

A Collection of Project Management Sayings

I thought the statements below made a lot of sense, or were humorous. I have many more that I will pass along soon.

Good estimators aren't modest: if it's huge they say so.

The sooner you begin coding the later you finish.

A verbal contract isn't worth the paper it's written on.

What is not on paper has not been said.

If you don’t know where you’re going, any road will take you there.

If you fail to plan you are planning to fail.

If you don't attack the risks, the risks will attack you.

A little risk management saves a lot of fan cleaning.

The sooner you get behind schedule, the more time you have to make it up.

A badly planned project will take three times longer than expected - a well-planned project only twice as long as expected.

If you can keep your head while all about you are losing theirs, you haven't understood the plan.

When all's said and done a lot more is said than done.

If at first you don't succeed, remove all evidence you ever tried.

Feather and down are padding - changes and contingencies will be real events.

There are no good project managers - only lucky ones.

The more you plan the luckier you get.

A project is one small step for the project sponsor, one giant leap for the project manager.

Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.

If everything is going exactly to plan, something somewhere is going massively wrong.

Everyone asks for a strong project manager - when they get him they don't want him.

Overtime is a figment of the naïve project manager's imagination.

Quantitative project management is for predicting cost and schedule overruns well in advance.

Good project managers know when not to manage a project.

Metrics are learned men's excuses.

For a project manager overruns are as certain as death and taxes.

If there were no problem people there'd be no need for people who solve problems.

Some projects finish on time in spite of project management best practices.

Good project managers admit mistakes: that's why you so rarely meet a good project manager.

Fast - cheap - good: you can have any two.

There is such a thing as an unrealistic timescale.

The more ridiculous the deadline the more money will be wasted trying to meet it.

The first 90% of a project takes 90% of the time the last 10% takes the other 90%.

The project would not have been started if the truth had been told about the cost and timescale.

To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.

Never underestimate the ability of senior management to buy a bad idea and fail to buy a good idea.

The most successful project managers have perfected the skill of being comfortable being uncomfortable.

When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.

If it wasn't for the 'last minute', nothing would get done.

Nothing gets done till nothing gets done.

Warning: dates in the calendar are closer than you think.

There is no such thing as scope creep, only scope gallop.

Anything that can be changed will be changed until there is no time left to change anything.

If project content is allowed to change freely the rate of change will exceed the rate of progress.

If you can interpret project status data in several different ways, only the most painful interpretation will be correct.

A project gets a year late one day at a time.

A project isn’t over until the fat check is cashed.

Powerful project managers don't solve problems, they get rid of them.

Tuesday, February 28, 2006

100 Rules for NASA Project Managers

These have been floating around the Internet for years, however they are still powerful and worth reviewing often. While the list is long, I believe that reading them is well worth your time. More information about the list is presented at the end of this posting.

The Project Manager

Rule #1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing.

Rule #2: A project manager must know what motivates the project contractors (i.e., their award system, their fiscal system, their policies, and their company culture).

Rule #3: Management principles still are the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it.

Rule #4: Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge.

Rule #5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot.

Rule #6: A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.

Rule #7: One problem new managers face is that everyone wants to solve their problems. Old managers were told by senior management—"solve your own darn problems, that is what we hired you to do."

Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.

Rule #9: The boss may not know how to do the work but he has to know what he wants. The boss had better find out what he expects and wants if he doesn't know. A blind leader tends to go in circles.

Rule #10: Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure but luck favors the competent hard working manager.

Rule #11: Never try to get even for some slight by anyone on the project. It is not good form and it puts you on the same level as the other person and, besides, probably ends up hurting the project getting done.

Rule #12: Don't get too egotistical so that you can't change your position, especially if your personnel tell you that you are wrong. You should cultivate an attitude on the project where your personnel know they can tell you of wrong decisions.

Rule #13: A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.

Rule #14: Most managers succeed on the strength and skill of their staff.

Initial Work

Rule #15: The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.

Communications

Rule #16: Cooperative efforts require good communications and early warning systems. A project manager should try to keep his partners aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The partners should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides his partners will be treated in kind and will be considered a person of no integrity.

Rule #17: Talk is not cheap; but the best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.

Rule #18: Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said.

Rule #19: You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager, and this means more than a
few classes from an online university. There are simple courses available to learn computerese, communicationese and all the rest of the modern "ese's" of the world. You can't manage if you don't understand what is being said or written.

People

Rule #20: You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job.

Rule #21: We have developed a set of people whose self interest is more paramount than the work or at least it appears so to older managers. It appears to the older managers that the newer ones are more interested in form than in substance. The question is are old managers right or just old? Consider both viewpoints.

Rule #22: A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews.

Rule #23: The source of most problems is people, but darned if they will admit it. Know the people working on your project to know what the real weak spots are.

Rule #24: One must pay close attention to workaholics—if they get going in the wrong direction, they can do a lot of damage in a short time. It is possible to overload them and cause premature burnout but hard to determine if the load is too much, since much of it is self generated. It is important to make sure such people take enough time off and that the workload does not exceed 1 1/4 to 1 1/2 times what is normal.

Rule #25: Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better.

Rule #26: If you have someone who doesn't look, ask, and analyze; ask them to transfer.

Rule #27: Personal time is very important. You must be careful as a manager that you realize the value of other people's time (i.e., the work you hand out and meetings should be necessary). You must, where possible, shield your staff from unnecessary work (i.e., some requests should be ignored or a refusal sent to the requestor).

Rule #28: People who monitor work and don't help get it done never seem to know exactly what is going on (being involved is the key to excellence).

Rule #29: There is no greater motivation than giving a good person his piece of the puzzle to control, but a pat on the back or an award helps.

Rule #30: It is mainly the incompetent that don't like to show off their work.

Rule #31: There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people, but get their work done as soon as possible. Getting the work done by someone else takes two or three times longer and the product is normally below standard.

Rule #32: People have reasons for doing things the way they do them. Most people want to do a good job and, if they don't, the problem is they probably don't know how or exactly what is expected.

Rule #33: If you have a problem that requires additional people to solve, you should approach putting people on like a cook who has under-salted the food.

Reviews and Reports

Rule #34: NASA has established a set of reviewers and a set of reviews. Once firmly established, the system will fight to stay alive, so make the most of it. Try to find a way for the reviews to work for you.

Rule #35: The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation.

Rule #36: Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses—just state facts.

Rule #37: External reviews are scheduled at the worst possible time, therefore, keep an up-to-date set of business and technical data so that you can rapidly respond. Not having up-to-date data should be cause for dismissal.

Rule #38: Never undercut your staff in public (i.e., In public meetings, don't reverse decisions on work that you have given them to do). Even if you direct a change, never take the responsibility for implementing away from your staff.

Rule #39: Reviews are for the reviewed an not the reviewer. The review is a failure if the reviewed learn nothing from it.

Rule #40: A working meeting has about six people attending. Meetings larger than this are for information transfer (management science has shown that, in a group greater than twelve, some are wasting their time).

Rule #41: The amount of reviews and reports are proportional to management's understanding (i.e., the less management knows or understands the activities, the more they require reviews and reports). It is necessary in this type of environment to make sure that data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence.

Rule #42: Managers who rely only on the paperwork to do the reporting of activities are known failures.

Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly.

Rule #44: Just because you give monthly reports, don't think that you can abbreviate anything in a yearly report. If management understood the monthlies, they wouldn't need a yearly.

Rule #45: Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know hundreds. Use them sparingly in presentations unless your objective is to confuse.

Rule #46: Remember, it is often easier to do foolish paperwork that to fight the need for it. Fight only if it is a global issue which will save much future work.

Contractors and Contracting

Rule #47: A project manager is not the monitor of the contractor's work but is to be the driver. In award fee situations, the government personnel should be making every effort possible to make sure the contractor gets a high score (i.e., be on schedule and produce good work). Contractors don't fail, NASA does and that is why one must be proactive in support. This is also why a low score damages the government project manager as much as the contractor's manager because it means that he is not getting the job done.

Rule #48: Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. The project management measurement system (PMS) should be used to verify the scores. Consistent poor scores require senior management intervention to determine the reason. Consistent good scores which are consistent with PMS reflect a well-run project, but if these scores are not consistent with the PMS, senior management must take action to find out why.

Rule #49: Morale of the contractor's personnel is important to a government manager. Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware developed by under- motivated people. You should take an active role in motivating all personnel on the project.

Rule #50: Being friendly with a contractor is fine—being a friend of a contractor is dangerous to your objectivity.

Rule #51: Remember, your contractor has a tendency to have a one-on-one interface with your staff. Every member of your staff costs you at least one person on the contract per year.

Rule #52: Contractors tend to size up the government counterparts and staff their part of the project accordingly. If they think yours are clunkers, they will take their poorer people to put on your project.

Rule #53: Contractors respond well to the customer that pays attention to what they are doing but not too well to the customer that continually second-guesses their activity. The basic rule is a customer is always right but the cost will escalate if a customer always has things done his way instead of how the contractor planned on doing it. The ground rule is: never change a contractor's plans unless they are flawed or too costly (i.e., the old saying that better is the enemy of good).

Rule #54: There is only one solution to a weak project manager in industry—get rid of him fast. The main job of a project manager in industry is to keep the customer happy. Make sure the one working with you knows that it is not flattery but on-schedule, on-cost, and a good product that makes you happy.

Engineers and Scientists

Rule #55: Over-engineering is common. Engineers like puzzles and mazes. Try to make them keep their designs simple.

Rule #56: The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.

Rule #57: The project has many resources within itself. There probably are five or ten system engineers considering all the contractors and instrument developers. This is a powerful resource that can be used to attack problems.

Rule #58: Many managers, just because they have the scientists under contract on their project, forget that the scientists are their customers and many times have easier access to top management than the managers do.

Rule #59: Most scientists are rational unless you endanger their chance to do their experiment. They will work with you if they believe you are telling them the truth. This includes reducing their own plans.

Hardware

Rule #60: In the space business, there is no such thing as previously flown hardware. The people who build the next unit probably never saw the previous unit. There are probably minor changes (perhaps even major changes); the operational environment has probably changed; the people who check the unit out in most cases will not understand the unit or the test equipment.

Rule #61: Most equipment works as built, not as the designer planned. This is due to layout of the design, poor understanding on the designer's part, or poor understanding of component specifications.

Computers and Software

Rule #62: Not using modern techniques, like computer systems, is a great mistake, but forgetting that the computer simulates thinking is a still greater mistake.

Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software.

Rule #64: Knowledge is often revised by simulations or testing, but computer models have hidden flaws not the least of which is poor input data.

Rule #65: In olden times, engineers had hands-on experience, technicians understood how the electronics worked and what it was supposed to do, and layout technicians knew too—but today only the computer knows for sure and it's not talking.

Senior Management, Program Offices, and Above

Rule #66: Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will astonish you.

Rule #67: Know your management—some like a good joke, others only like a joke if they tell it.

Rule #68: Remember the boss has the right to make decisions. Even if you think they are wrong, tell the boss what you think but if he still wants it done his way; do it his way and do your best to make sure the outcome is successful.

Rule #69: Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you can't.

Rule #70: You and the Program Manager should work as a team. The Program Manager is your advocate at NASA HQ and must be tied into the decision makers and should aid your efforts to be tied in also.

Rule #71: Know who the decision makers on the program are. It may be someone outside who has the ear of Congress or the Administrator, or the Associate Administrator, or one of the scientists—someone in the chain of command—whoever they are. Try to get a line of communication to them on a formal or informal basis.

Program Planning, Budgeting, and Estimating

Rule #72: Today one must push the state of the art, be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long as the ground rules such as funding profile and schedule are established up front and maintained.

Rule #73: Most of yesteryear's projects overran because of poor estimates and not because of mistakes. Getting better estimates will not lower costs but will improve NASA's business reputation. Actually, there is a high probability that getting better estimates will increase costs and assure a higher profit to industry unless the fee is reduced to reflect lower risk on the part of industry. A better reputation is necessary in the present environment.

Rule #74: All problems are solvable in time, so make sure you have enough schedule contingency—if you don't, the next project manager that takes your place will.

Rule #75: The old NASA pushed the limits of technology and science; therefore, it did not worry about requirements creep or overruns. The new NASA has to work as if all projects are fixed price; therefore, requirement creep has become a deadly sin.

Rule #76: Know the resources of your center and, if possible, other centers. Other centers, if they have the resources , are normally happy to help. It is always surprising how much good help one can get by just asking.

Rule #77: Other than budget information prior to the President's submittal to Congress, there is probably no secret information on a project—so don't treat anything like it is secret. Everyone does better if they can see the whole picture so don't hide any of it from anyone.

Rule #78: NASA programs compete for budget funds—they do not compete with each other (i.e., you never attack any other program or NASA work with the idea that you should get their funding). Sell what you have on its own merit.

Rule #79: Next year is always the year with adequate funding and schedule. Next year arrives on the 50th year of your career.

The Customer

Rule #80: Remember who the customer is and what his objectives are (i.e., check with him when you go to change anything of significance).

NASA Management Instructions

Rule #81: NASA Management Instructions were written by another NASA employee like you; therefore, challenge them if they don't make sense. It is possible another NASA employee will rewrite them or waive them for you.

Decision Making

Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them.

Rule #83: Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss, but if you constantly have to solve someone's problems, you are working for him.

Rule #84: Never make a decision from a cartoon. Look at the actual hardware or what real information is available such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.

Professional Ethics and Integrity

Rule #85: Integrity means your subordinates trust you.

Rule #86: In the rush to get things done, it's always important to remember who you work for. Blindsiding the boss will not be to your benefit in the long run.

Project Management and Teamwork

Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays.

Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity.

Rule #89: Whoever said beggars can't be choosers doesn't understand project management, although many times it is better to trust to luck than to get poor support.

Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion.

Rule #91: Remember, the President, Congress, OMB, NASA HQ, senior center management, and your customers all have jobs to do. All you have to do is keep them all happy.

Treating and Avoiding Failures

Rule #92: In case of a failure:
a) Make a timeline of events and include everything that is known.
b) Put down known facts. Check every theory against them.
c) Don't beat the data until it confesses (i.e., know when to stop trying to force-fit a scenario).
d) Do not arrive at a conclusion too fast. Make sure any deviation from normal is explained. Remember the wrong conclusion is prologue to the next failure.
e) Know when to stop.

Rule #93: Things that fail are lessons learned for the future. Occasionally things go right: these are also lessons learned. Try to duplicate that which works.

Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.

Rule #95: History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards.

Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.

Rule #97: Don't be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.

Rule #98: One of the advantages of NASA in the early days was the fact that everyone knew that the facts we were absolutely sure of could be wrong.

Rule #99: Redundancy in hardware can be a fiction. We are adept at building things to be identical so that if one fails, the other will also fail. Make sure all hardware is treated in a build as if it were one of a kind and needed for mission success.

Rule #100: Never make excuses; instead, present plans of actions to be taken.

Jerry Madden, Associate Director of the Flight Projects Directorate at NASA's Goddard Space Flight Center
Updates to this list and full credit for contributors can be found here