Triple Constraints

I had a conversation the other day with a colleague who told me that at their company they were told to never tell the client no. I was dumb-founded. Obviously, there must have been times when they were allowed to tell a client no. He informed me that they, as project managers, were never allowed to tell a client no. If they got a request, and the team could do it, then they must say yes and deliver.

I asked what happened when the team couldn’t deliver. He stated that since his old company was a services company, the requests he received could always be solved by throwing additional resources as the task. And thus, he was “fortunate” enough to never have to say no.

However, many people work on projects that can’t be solved by simply throwing more resources at the problem. How are project managers on these projects supposed to respond?

Is it OK to tell a client no?

Personally, I think it is OK to say no. Clients obviously do not like hearing the word no, but as long as you can explain the reason the request can’t be accommodated they tend to be ok with the outcome. As long as you give the client all the information that leads to your decision and rationally explain to them why you have to say no, they will understand where you are coming from.

When is it OK to tell a client no?

It is acceptable to tell a client no in several situations. They are:

• When the request cannot possibly be fulfilled/satisfied
• When the request can be fulfilled, but it will put the rest of the project at risk
• When the request can be fulfilled, but does not help the project at all

What if the request can be done, but is out of scope?

Sometimes, you will come across a request from a client that can be fulfilled and will not put the project at risk. However, the request is outside of the scope of what the client has contracted for. What do you do in a situation like that? Every company has their own stance on this question, but personally I think that each request has to be individually analyzed:

• If the request requires low effort and delivers low reward, then the request can be fulfilled after all other requests are fulfilled
• If the request requires low effort and delivers high reward, then it makes sense to satisfy the request
• If the request requires high effort and delivers low reward, then it does not make sense to satisfy the request
• If the request requires high effort and delivers high reward, then the request can be fulfilled after all other requests are fulfilled

Conclusion

So, in conclusion, it is OK to tell a client no. If you have analyzed the situation and have determined that saying yes to the request would cause the project harm or would not return adequate value, then you are allowed to and have the obligation to tell your client that the team’s time would be better spent focusing on other tasks.

Feedback

How do you decide if you are going to tell the client no? How do you tell the client no?

Watching March Madness, I can’t help but notice the amount of upsets in the tournament.

I also couldn’t help but notice how poorly my bracket was faring.

• Superior teams were losing to inferior squads.
• Star players were being outplayed by inferior players.

So why is it that there is such unpredictability in sports?

The debate in sports has always been:

What wins championships…players or systems?

Players often like to think that they make the difference in the game. Employees like to think that they make the difference on their projects.

Coaches and managers like to think that the system is more important than the players/employees they use.

So who is right?

The answer is that both sides are.

• Without the right players, no team can win. Without the right team members, no project will succeed.
• Without the right game plan, no team will win. Without the right methodology/plan, no project will succeed.

In the end, the game (and the project) depend on all the pieces aligning correctly:

• You must have the proper vision
• You must work together
• You must have the right team members.

So work your hardest to assemble your team, train them hard, and motivate them to do their best. If you do all of this, you will always give yourself a shot at winning.

Any good project manager will tell you that documenting and following up on action items is a key to a successful project. With all the tools at a project manager’s disposal, what should you use to track action items. Below is a list of tools I have run across for managing action items:

Microsoft Excel

Pros

• Small learning curve
• Easy to distribute/collaborate with team members

Cons

• Not web-based
• Tasks are not directly tied to the project schedule
• No automatic notifications
• Easy to get out-of-sync due to team members making changes to their local version
• Project manager has to make all updates to tasks

Microsoft Project

Pros

• All project tasks can be tied to the project schedule

Cons

• Steeper learning curve than Excel
• Requires the project manager to manually update all tasks
• Not web-based

Online To-Do Software (Such as RemembertheMilk.com)

Pros

• Easy to learn
• Very affordable (in some cases free)
• Web-based
• Can share/assign tasks to team members
• Team members can automatically mark tasks as complete
• One central list of tasks for a project
• Tasks can be accessed/updated from mobile phones

Cons

• Tasks not tied directly to timelines
• Data resides on external servers

All of the above tools have their strengths and weaknesses. No one solution is the silver bullet for managing action items, but all of them below in the project manager’s tool belt.  If you have other tools that you recommend to your colleagues, please share them with your fellow readers below.

And remember – No matter what solution you use, make sure that you actively manage the action items for your project. If you neglect the action items, you are acting neglectful towards your project.

We all have been on a project where timelines are missed. It is unfortunate, but it happens. We spend all our time scrambling to recover from missed timelines, but we rarely spend enough time looking at the root causes of the miscues. Missing timelines is detrimental to our projects and to our careers.

Below are some of the most common causes for missed timelines during the initiation and planning phases of the project.

Going into battle with the wrong army – we all know the difference a great team can make on your project. Having people you can trust to accomplish their tasks can make a tremendous difference. Spend time in the beginning of the project securing the resources that you need to execute your project. Any effort you spend fighting for resources will be more than offset by the effort you don’t have to spend compensating for poor performers on your team.

Misunderstanding your orders – not knowing what your team needs to accomplish is certain to lead to missed timelines. It may sound obvious, but incomplete or incorrect requirements are too often the culprit for missed timelines. Make sure that you work with your clients to clearly define what is expected of you and your team. This will instill confidence in your clients and will ensure that you lead your team to success.

Underestimating your foe – too many teams fail because they fail to accurately estimate how long their tasks will take to accomplish. Some of this is overconfidence in their abilities, while some of it is due to uncertainty surrounding the tasks or the project. Make sure you work with your team to accurately estimate task durations. Use historical data as an input into your estimates when possible. Instill in your team that the estimates they come up with are what they are committing to. This will force them to closely examine their estimates.

In part 2 of this series I will look at the most common causes of missed timelines during the execution phase of a project.

As the year 2009 comes to an end, many people are getting ready to make New Year’s Resolutions. Many of these are the ones we hear year in and year out:

• Lose weight
• Quit smoking
• Stop drinking
• Get out of debt

These are all noble goals and I wish those people making these resolutions the best of luck in trying to keep them. I too will be making some resolutions this year, but mine are focusing on how I conduct myself as a project manager. Here they are:

#1 Listen more than I speak
One of the key responsibilities of a project manager is to know what is happening with their project. This involves working with all team members and stakeholders to learn the current state of the project. This may seem like it requires extensive speech by the project manager, but experience project managers know that it takes just a little prompting to get your stakeholders and team to open up and provide you with the project’s temperature.

#2 Focus on my team, and not my computer
Project management software is everywhere we turn. It promises to make us better project managers and to make our projects run smoother. Project management software is a useful tool in the project manager’s arsenal, but it is not a predictor of project success. I will admit that in the past I have become enamored with PM software, but I learned that to make my projects truly succeed I needed to focus on my team. The team is what accomplishes tasks. The team allows me to meet deadlines. The team is responsible for delivering a quality project.

#3 Answer questions before they are asked
While it seems to run contradictory to #1, this resolution does not. This year I am going to do my best to proactively address team and stakeholder questions. Project managers often know what the stakeholders/customers need to know, but we often wait for the question to be asked because we hope it will give us more time to remedy any bad situations or increase the positives we can report on.

#4 Accept responsibility for more blame
Project managers are people. As such, we attempt avoid negatives in our lives. One such negative is blame. Many people do anything they can to avoid blame. This may temporarily make them feel better, but in the long run it can only hurt more. By accepting blame during the course of a project, project managers help their team build a sense of camaraderie because they feel that they are working together instead of just being led by the PM. Also, accepting blame professionally can actually help your career because it shows your boss that you understand the importance of accountability. Now don’t get me wrong…I am not saying that you should accept the blame for all things that go wrong on your project. Instead, take responsibility for those things that you could have impacted.

I believe that these resolutions will help me be a better project manager in the coming year and for years to come. I hope that you think about how you manage your projects and come up with resolutions for yourself. Please feel free to share your resolutions with your fellow readers below so that we can all improve ourselves in 2010.

This past Christmas weekend, I visited my wife’s family. It was a lovely time and we had lots of good conversations. One of the conversations we had was about careers. Most of the family is out of college, and we all have different careers. One is a lawyer, one is a salesperson, one is in marketing, one is an engineer, and I am a project manager. Most of the other professions are easy to explain, but mine is more difficult.

After explaining to them the basics of what project management is, I was left to detail how I got into project management. This sounds like a simple topic, but it was not straight forward. I was a psychology major in college and never thought about a career in project management.

My first few jobs after college were not what you would call project management jobs, but they did require many of the same skills that project management requires. And they all seemed to lead me down a path that resulted in project management as a career.

One of these jobs was as the assistant manager of a golf course. One of the responsibilities of this job was to facilitate and arrange corporate golf outings to our resort. The skills that were required for this job were organization, prioritization, and communication. These same skills are essential for the successful management of projects.

Another of my earlier jobs was as an Information Systems Coordinator. This job required that I work with various stakeholders to define business processes and requirements for newly-developed internal systems. This job helped me to gain experience in requirements gathering and stakeholder management. It also shifted my career from more service-centric to increasingly technology-centric jobs.

After this job, I received several more technology-heavy jobs. These jobs all required that I increase my technical aptitude and my ability to manage the deployment of the systems I was involved in. It was this responsibility of overseeing the deployment of systems and projects that ultimately led me to project management. I noticed that my interest and passion laid with ensuring that my stakeholders and customers were satisfied with what I, and the rest of my team, delivered.

It was at this point that I began to more rigorously attempt to increase my project management knowledge:

• I read every project management book I could get my hands on
• I took online training courses that prepared me for the PMP exam
• I listened to project management podcasts
• I attended project management events and conferences

It is this combination of experience, training, and involvement in the project management community that has brought me into the project management fold. It has been a winding path from being a psychology major at Notre Dame to being a project manager for a technology firm, but it has been a path I am glad I walked down.

Now I ask you the same question that was the impetus for this post:

How did you get into project management?

A few months ago, I wrote a post entitled “How Football Coaches are like Project Managers“, which compared project managers to football coaches. The article discussed how coaches, like project managers, are responsible for the following:

• Procuring superior talent
• Preparing the team
• Motivating the team

When a coach accomplishes the above tasks, they are likely to have a successful tenure. This is evidenced by trophies, rings, and accolades.

However, it is more often the case where a coach is not able to accomplish all of the above tasks. When this happens, the team does not win enough, and eventually the coach is let go. This recently happened when my alma mater decided not to retain Charlie Weis as head coach. It was not his lack of commitment, effort, or passion that caused him to lose his job. It was the lack of wins over the past few years.

Project managers are also judged by the bottom line.

You may have assembled and trained a dynamic team. You may have motivated the team to work hard for you. You may be liked by your superiors. However, do not be complacent because of these factors. Any project manager knows that he/she is only judged by the success of their last project. A project fails or succeeds because of the entire team, but as the sports cliche says, “You can’t fire the whole team”. When the project fails, it is often the project manager who bears the brunt of the responsibility.

However, there is the flip side. When a project succeeds, the project manager is often the one who receives the lion’s share of the praise. We can all think back to when we were riding high after the success of an important project.

The bottom line is that we, as project managers, know where we stand. We are accountable for the success of a project and we cherish that responsibility. We like assembling our team and going to battle with them. We enjoying helping our players grow on the field of play. And most of all, we like looking up at the scoreboard when time has expired and seeing that we have won.

When many people think of project management they think of rigid adherence to rules and defined process. They often envision a project manager sitting in front of his/her laptop receiving updates from the team, entering it into Microsoft Project, and then creating status reports. While this may be the case for many projects, it does not do justice for the true role of the project manager.

Many readers of this blog, and of other project management articles, believe that project management is all about people and communication management. This hits closer to home in terms of the real responsibilities of a project manager. The project manager is not just a robot who receives information and databases it; rather he/she is an active participant in the conversation that is project management. The project manager is constantly communication with team members and all project stakeholders. They receive constant updates on the project and then work to utilize that information to make sure all parties are informed so that progress can be made.

In reading the book The Speed of Trust by Steven Covey, a book I highly recommend, I came to further realize the role that trust plays in project management. As the author points out in the book, trust is an attribute that can contribute to the success or failure of a project as much as any other.

Let’s examine how trust can impact your project:

The project manager must trust that the project team is being honest about task estimates.

We all hear stories where project teams pad the estimates for how long tasks will take to complete only to have the project manager reduce the time because they know the team is padding the estimate. This is counter-intuitive in that it requires additional time/energy to complete the estimation/planning phase of the project. If the team and project manager trust and respect each other, then the process can be smoother and no one will feel that they are being manipulate.

The project manager must trust that the stakeholders are being honest about requirements.

When a project is in the requirements phase, the stakeholders have a great deal of input into the direction of the project. If this direction is not accurate, then the entire project is off-track from the onset. Sometimes the stakeholders are not sure about all requirements, and this is ok. There are entire agile methodologies designed to handle situations where all the requirements are not known or clearly understood. It is up to the stakeholders to define the requirements clearly up front or to alert the team that there are many unknowns.

The project team must trust that the project manager is keeping them informed of all changes to the project(requirements, schedule, etc.)

The project team is responsible for the creation of all project deliverables. As such, they need to be aware of any changes that may occur to what and when they must deliver. This ties into communication, but the project manager needs to instill confidence in the team that they are heading in the right direction. This can most easily be accomplished by being open and honest with the team. This trust will help the project manager manage and motivate the team as well.

The stakeholders must trust that the project manager is keeping them informed of all changes to the project (costs, schedule, etc.)

The project manager is ultimately responsible for the success of the project and they are accountable to the stakeholders. The stakeholders hate nothing more than to be surprised on the date of a deadline with the news that the project is missing its milestone. Also frustrating for the stakeholders is to be informed by the project manager that the project is significantly over budget. Both of these situations can result in the project being terminated prior to completion. One way to ameliorate this situation is to be honest and open with the stakeholders whenever things are slipping. Don’t get me wrong, they won’t enjoy hearing this unpleasant news. But at the same time, they will respect you for being honest about the situation and this can lead to them giving you a little more slack.

In Conclusion

We have examined some high-level ways in which trust and honesty can improve the health of your project. It is not always the easy thing to be honest at all times with your team and stakeholders, but the benefits of establishing truest are worth it. A team that trusts you will often work harder for you. Stakeholders that trust you will often give you the benefit of the doubt.

The effects of not being trusted are not something that you  want to encounter. They are manifested by a team that does not put full effort into the project and stakeholders that hedge their bets when it comes to the project and your career. So be sure that you treat trust as a resource that needs to be vigilantly protected.

In August, I penned an article that discussed the differences between waterfall and agile project management methodologies. As stated in that article, waterfall is more appropriate when requirements are clearly understood and there is not much fluctuation. Agile methods are more appropriate when there is flux and when requirements are not clearly understood.

One of the most popular agile methodologies out there is Scrum. Scrum was originally designed for the management of software projects, but has since been applied to other genres of projects. Scrum was first described in the 1980’s but did not become mainstream until the 90’s.

The scrum project is conducted by a product owner, a Scrum Master, and the project team (oftentimes developers).

The product owner is responsible for supplying the requirements from the viewpoint of the users. The Scrum Master is responsible for facilitating (not managing) the project and making sure the team is in a position to succeed. The team is responsible for the execution of the project.

The basic flow of a scrum project is the following:

1. The product owner creates a list of desired features. This is known as the product backlog.
2. The project team then determines how many of these features they can deliver within the Sprint (timebox of development and testing). They call this list of features they will deliver in the sprint the Spring backlog.
3. Each morning the team meets to provide an update to eachother on the status of each item within the Spring Backlog.
4. After the Sprint has completed (and hopefully all items developed and tested) the team provides a demonstration of the system to the product owner and other stakeholders. The team receives feedback and incorporates this into the product backlog.
5. Steps 2 through 4 are then repeated until the product reaches a final state.

If you would like more information on Scrum, please visit http://www.scrumbasics.com.

Watching my alma mater Notre Dame dismantle Nevada this past Saturday, I couldn’t help but think that there were three main things that allowed ND to win the game:

1. Superior talent
2. Preparation
3. Motivation

Having one of these things without the others would not have let the team win. This may seem like common sense in the sporting world, but it also applies to the business world. Charlie Weis was able to get his team ready for the game and they won in convincing fashion. Charlie serves as a project manager and boss for one of the most stressful jobs in the country. We can apply some of his practices into our own lives.

When you are kicking off a project, you are like the coach of a football team. You have been given the task of guiding your team over the goal line and on to victory. Now what do you do to help your team win?

Talent

First, you need to make sure you have the talent on your team. In the world of college football, this is called recruiting. In the world of project management this is called resource procurement. In both cases, you have to plead your case as to why the talent (player or employee) should be part of your team. In college recruiting, you need to explain how you can help the player/employee develop and pursue their goals while they work to solve the goals of the team. In business, the majority of the recruiting pitch is aimed at the functional manager. You need to explain how having the employee on the project will help the company succeed.

Preparation

Next, you need to prepare your team for the big event. This involves analyzing your own team, your opponent (or project in the business scenario), and figuring out ways to put your players in a position to succeed. No one coach can do this on their own and this is why there are scouts and assistant coaches. The same principle applies to the project management world. Successful project managers partner up with business analysts and other resources that specialize in defining projects and recognizing risks and opportunities.

When analyzing your own team you need to look back at previous performances and evaluate how players performed. You work on fixing those things that broke, while reinforcing and practicing those things that went well so they continue to work. In the sports world that is simply called practice, but in the business world these tasks occur during lessons learned meetings and best practices sharing.

Motivation

Notre Dame players are motivated this year to prove that previous years were a fluke and that the team has the talent to challenge for a national championship. This motivation to prove others wrong is often a strong force for teams. Players on a team are also motivated by a desire to showcase their talents in the hope of attracting the attention of scouts.

These same principles are at stake on a project team. Team members are motivated to perform well because they want the project to succeed. This is often epitomized by the “us versus them” mentality that many teams embrace. They also work hard because they desire recognition from peers and managers. How can a project manager increase motivation within the team? One key way is to be honest at all times. Tell your team how it is, not how they want it to be. When you provide feedback to your workers focus on giving them actionable information so they can continue to grow as employees.

Conclusion

Take this information and apply it to your next project. And remember, win one for the Gipper!