Be Prepared

April 21, 2008 – 5:50 am by Andy Wergedal

Be Prepared

We cannot totally predict what will happen during a project but we can be prepared for those eventuallities.

How would you handle the following:

What happens to the project if a Star gets hit by a bus (becomes incapable of work)?
What happens if you lose funding or the company is sold/bought?
What happens if the ”shared” repository/directory is deleted?
What happens if you get replaced?
What happens if the project priorities get changed?
What happens if you realize that you cannot complete the project on time, on budget, with the staff you have?
What happens if everyone (or their kids) gets sick? for a week?
What happens if the project Sponsor quits?
What happens if another project becomes the priority?
What happens if your political rival gets promoted and inherits your project?
What happens if someone offers you a better position with double the pay?

There is no right answer, except that you must prepare a list and have an answer to each of the questions on your list.

Simple Easy and Fast

April 14, 2008 – 5:50 am by Andy Wergedal

How do you know if your IT systems will be successful with real humans? Just ask three questions…

Is it Simple to use?
Is it Easy to understand?
Is it Fast to execute?

Here are my basic definitions of the criteria…
Simple: the art of providing enough value without becoming a burden on the environment.
Easy: when normal people can complete a task without instruction.
Fast: the system responds before the human can predict or request the next action.

If each answer is yes, then your system will probably be successful. If it is complicated, convoluted and slow, it will be a disaster. Ask these three questions and you will be very close to the target.

Star Factor

April 7, 2008 – 5:50 am by Andy Wergedal

When you arrive at a new project, write down the names of the superstars. There will be 10-20% of the team are the high producers. You can identify them as the motivated participants that everyone talks to and works to gain their approval. Write down these names and watch the progress, growth and enthusiasm of these key stake holders. These are the stars of your project.

During your monthly review of stakeholder management, rank each of these stakeholders on their participation, motivation, energy and willingness to help work through the current issues. The rest of the team will find these people (stars) easy to work with and motivating. If you have a really good core team of stars you will appear to be the best project manager in the world.

Although it is expected to have some churn during a project. Keep a close eye on the stars. If at any time you find that a star is gone replace them immediately. You need to have someone other than yourself to carry the load. Make it your personal mission to identify and nurture these stars.

If you suddenly find that you are the only one left, your project is probably already dead.

Low performers

March 31, 2008 – 5:50 am by Andy Wergedal

Why do projects fail? Management of resources and communication are the keys. When you find yourself in the difficult position of identifying a low performer, your job is to replace them. Hopefully they can better serve the team in a different role, but if not you must replace them. Can you afford the have the project fail because of this person? If this was war and you would all die, would this change your perspective? Give them another role or get them off the project.

Of course, It is difficult and uncomfortable to give bad news. We would not be human if it was not difficult. The least painful way is to start doing this from day one. Tell the truth and do not pull punches. Softening the message will only hurt everyone because it means that you are lying. Tell the whole ugly, naked facts when coaching the low performers. The need to hear the truth. It is not personal if you have kept the facts, failure to deliver according to the schedule is one of the most common reasons.

If you do not replace low performers your project will fail and it will be your fault.

Managers make sure things get done

March 24, 2008 – 5:50 am by Andy Wergedal

Have you ever said, Just assign it to me and I will do it.? This is the classic mistake for a project manager. I like to view a project manager as the captain of a ship. The captain does not set the sails or turn the wheel. Their job is to make sure that the ship, its crew and cargo arrive safely at the destination. When the storm comes everyone turns to the captain for leadership and direction. This is accomplished by requiring the crew (or team) to do their jobs.

If you start to do the work of the team then you are causing two problems both are fatal. The first problem is that you diminish your authority because you cannot get the team member to perform. The second problem is that the rest of the team will default their problems to you, instead of finding a way to solve them. Both of these problems will cause the project to fail and it will be your fault.

So, what should you do? Ask the magic question… “What do you need to help you complete this task?

A manager does not do things, they make sure things get done.

Are all meetings necessary?

March 17, 2008 – 5:50 am by Andy Wergedal

MeetingsYes and No.

Is life just a series of unnecessary meetings? Status meetings could be replaced with an issues meeting and a written status update. Issues meetings could be replaced with people actually identifying and fixing the issues. Management meetings could be replaced with coaching sessions (for the managers). Communication meetings are the only really important meetings because nothing can take the place of face to face communication and building a real trusting relationship with the other person.

Have we become too scared to talk face-to-face, forcing us to use email, text messages, chat and voice mail to communicate?

Use meetings effectively to communicate, build consensus and relationships.

Capt Obvious version of Project Management

March 10, 2008 – 5:50 am by Andy Wergedal

Too many times we (PM’s) over think our tasks. We like to get into list organizing and reporting metrics because we are geeks. We are very comfortable reading our charts and graphs. We seek out the best formulas to use and metrics to show and validate our value. But, does this alone serve our clients? Does it add value to our discipline, or does it detract from the perception of a PMP? I submit that we (PM’s) need to simplify our process and procedures into the most basic terms.

Here are the basics of the PMBOK condensed into the Capt. Obvious terms…

  1. Make “the plan” (how you are going to run the project)
  2. Talk with the client
  3. Establish “the list” of deliverables
  4. Sequence “the list” by adding the dependencies
  5. Assemble “the team” needed to complete “the list”
  6. Get “the team” to determine “the time” necessary to do each task (duration)
  7. Combine “the list”, “the team”, “the time” and you will end up with “the schedule” and milestones
  8. Execute

Can you believe what they say?

March 3, 2008 – 5:50 am by Andy Wergedal


When you start a project, ask each stakeholder what they personally want out of the project. This creates a personal relationship with each stakeholder and demonstrates your concern with them and their Needs. To gain the trust necessary to dig out these goals, you must be honest and up front about your intentions and project boundaries in a non-formal, casual way. Usually, you will encounter some answers that do not match the documented or verbalized goals. Do not worry about whether the stated goals are real, perceived or petty… just remember them. Each stakeholder will have various personal,professional and corporate goals.

After you have spoken with each of the stakeholders, have a public kick-off meeting and ask all of the stakeholders to be present. State the documented written goals in the contract and ask if everyone agrees. The purpose of this meeting is to establish your position, gain trust from the stakeholders and set the expectations about the deliverables and time lines. You can expect some discussion about these points.

Watch the stakeholders… if their actions reflect their words, you can believe what they say.
If their words and actions are in conflict, only believe what they do.

Goals

February 26, 2008 – 5:05 am by Guest Contributor


A familiar story: We are trying to defend an area from the enemy and have set up some fire bases. A squad of men with small arms behind a sandbag barrier will shoot at the enemy from these fire bases. The bases will be much more effective and the men safer if they can support each other with small arms fire so we carefully measure the elevation and place the bases on high ground for maximum vision, clear jungle and some old buildings to improve the line of sight, and install firing platforms to improve stability and accuracy. We demonstrate the effectiveness of this configuration via simulations and congratulate ourselves on a job well done. Oh, remember those old buildings?

Yes senator, it became necessary to destroy the village in order to save it.

We have all seen and done this many times on our projects: gotten so tied up with tasks and process that we lose sight of the goal.

Contributed by Brian Mason, bmason@itassociates.com

Put your client first

February 25, 2008 – 5:50 am by Andy Wergedal

Who is your client? As a contractor I am hired by a recruiting firm, who supplies me to a service integrator, who is delivering a project to their client. Confused? You bet, there are four different entities involved in the transaction.

Fortunately, it is easy to determine my client. My client is the entity who pays my invoice. Here is an example, Big Consulting Company hires me to help deliver a new ERP system to Giant Oil Company. My client is Big Consulting Company because they pay my invoice.

This is a problem when your client’s needs conflict with the delivery of the project. Take staffing for example. Do you hire the best you can find, or the cheapest? The Big Consulting Company has to make margin to survive. Sometimes your staffing and budget constraints are in direct conflict with delivering a high quality product. With a contract in hand, the choice is clear. You must act in the best interest of your client.

Identify your client and then put them first.