Strategic Project Management

I just returned from Baltimore where I attended the  Mid-Atlantic Regional Conference 2012 of Educause. I was invited to co-present with Scott Sax of Loyola University regarding how they approach projects, operational initiatives and other work done within their IT organization. The presentation was well-received and it was certainly a pleasure to be associated with such an exemplary organization as the crew from Loyola.

Aside from our presentation yesterday, Rich Sigler, the director of the PMO at Loyola gave an excellent presentation about how he perceives the responsibilities of his PMO. the title of his presentation was: Technology Project Selection and Governance at Loyola University Maryland. It was outstanding, one of the best presentations I've seen on this topic.

He compared establishing a PMO to building a playhouse for his daughters. He suggested that the PMO needs the following four walls and roof:

1. A portfolio of projects
2. A project management process
3. An information system
4. A support strategy

He described how (in his opinion) the PMO's responsibility was to promote a best practice approach to managing projects. I agree. Part of those best practices include how projects are selected for inclusion in the portfolio. It was a real commonsense approach to submission and prioritization I think is worth discussing here.

"Any member of the Loyola community can instigate a project request," says Sigler. "The request is really a pitch that sells the idea of the project to the committee that makes decisions about whether or not any individual project will be pursued."

Their governance committee evaluates any potential project based on some very simple criteria that includes "impact" and "effort". They describe how projects are scored like this:

1. Quick Win: High Impact/Low Effort
2. Strategic: High Impact/High Effort
3. Nice to Have: Low Impact/Low Effort
4. Declined: Low Impact/High Effort

They also include in the evaluation whether or not there is a regulatory component or if the project is underway (those projects automatically take priority). The idea is to ensure that the project teams aren't expected to do more than what they can realistically accomplish during the course of the average semester (which is their normal project timeline).

I like the nature of this simple approach. It gives them the opportunity to evaluate potential projects in a manner that everyone in the community can understand and gives potential project sponsors a baseline for making their project request.

Einstein once said something like, "Any idiot can make things more complicated, it takes real genius to make something simple."

I think Rich and his team at Loyola have done that with this process. Of course, I've left out a lot of the details, but I'm convinced that the four walls and the roof they've build for their PMO "playhouse" puts them in a great position to prioritize and focus the project teams at Loyola on the work that will provide the most value to their organization.

What are you doing to prioritize projects and keep people focused on the things that are most important?

As many of you know, I'm a pretty consistent reader. A few months ago, I picked up a new book, The Lean Startup, by Eric Ries. I read it at the recommendation of my boss and have found it to be a very informative book about creating an environment of innovation and growth.

Project-based work is messy and fraught with risk. In fact, I'm pretty convinced that dealing with failures of one sort or another is just part of the equation. With that in mind, Ries describes what feels to me like a simple and logical approach to getting to the root cause of the problem. Of course, I won't be able to do it justice within a blog post, but the book is well worth the read and chapter 11 is where you will find the "Wisdom of the Five Whys".

"The core idea of the Five Whys is to tie investments directly to the prevention of the most problematic symptoms," writes Ries. "The system takes its name from the investigative method of asking the question "Why?" five times to understand what has happened (the root cause). If you've ever had to answer a precocious child who wants to know "Why is the sky blue?" and keeps asking "Why?" after each answer, you're familiar with it. This technique was developed as a systematic problem-solving tool by Taiichi Ohno, the father of Toyota the Production System..."

Ries suggests, and I wholeheartedly agree, that "At the root of every technical problem is a human problem. Five Whys provides an opportunity to discover what the human problem might be..."

Ries presents an example that Ohno often gives to illustrate the point:

"When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though is sounds easy. For example, suppose a machine stopped functioning:

1. Why did the machine stop? (There was an overload and the fuse blew.)
2. Why was there an overload? (The bearing was not sufficiently lubricated.)
3. Why was it not lubricated sufficiently? (The lubrication pump was not pumping sufficiently.)
4. Why was it not pumping sufficiently? (The shaft of the pump was worn and rattling.)
5. Why was the shaft worn out? (There was no strainer attached and metal scrap got in.)

"Repeating "why" five times, like this, can help uncover the root problem and correct it. If this procedure were not carried through, one might simply replace the fuse or the pump shaft. In that case, the problem would recur within a few months. The Toyota production system has been built on the practice and evolution of this scientific approach. By asking and answering "why" five times, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms."

I like the simplicity of this approach. In fact, I've used similar approaches in the past to great success. Be aware, the answers to the Five Whys are sometimes hard to take. Sometimes it takes some intestinal fortitude to go through through this exercise—as was mentioned before, at their core, most technical problems are really people problems.

Of course, this is nothing new. I'd be very interested to hear if any of you have had experience with the Five Whys and how it worked for your team.

Benjamin Franklin said, "In this world nothing is certain but death and taxes."

Implementing change is never easy. When change does happen, particularly within the project management process, most of the common implementation problems are really excuses—not roadblocks.

Knowing (and then educating everyone involved with the change) upfront about what to expect can make the culture shock a little easier to deal with. I've noticed over the years that "fear of change" in most cases is a fear of the unknown. Here are some of the most common fears that organizations face as they try to implement new methodologies:

1. It's different. Realizing that there are some people who really thrive on change, but most people don't, is important. You might get push-back simply because it's a change. I think the key here is to understand that sometimes it takes time for people to embrace the change. Whether it's a new practice, a new process or a new boss—giving people time to accept change is important.
2. Some people (managers and team members) are uncomfortable with the additional scrutiny that often accompanies change. If your organization is implementing a project review process to evaluate potential projects, some stakeholders might be a little nervous that their proposed projects might not stand up up to peer review. It's important to realize that projects that might be important to one senior manager or stakeholder might not be important to another. Making the review process transparent and understandable to everyone often helps reduce those types of concerns.
3. Some projects are more important than others. Implementing a sound work management methodology will mean only those projects that provide the most business value will get pushed forward—not the  "pet" projects of influential stakeholders. Because this might negatively impact some projects, there are stakeholders that may try to block the process.
4. There are tough decisions to be made. Sometimes it's not easy for decision-makers to make choices regarding projects and people, but it has to happen. It's important that senior managers understand that they have a responsibility to the organization—not just their individual departments or careers. There will be some who don't like this fact.
5. Implementing change takes time. Regardless of the change, it never happens overnight. It takes time to implement new methods, it takes time for people to accept the change and accommodating for  that time is crucial for change initiatives to be successful.

With any change, there will be those who embrace the change and others who don't. Be prepared for both and your efforts will be successful. What are some of the challenges you have successfully faced when implementing change.

The other day I was talking with a friend who told me about a book he had recently read, Seal Team Six: Memoirs of an Elite Navy SEAL Sniper. He shared an anecdote about one of the SEAL team support staff who was driving the team in a van home from a night on the town relaxing. While on the way home, a group of bullies in another vehicle started hassling the driver, unable to see the SEAL team in the back. After a few less than complimentary verbal exchanges, the van and the car of bullies pulled over to have it out. Once the the sliding door of the van opened and the  SEAL team emerged, the bullies realized they had written checks they couldn't cash.

"How often does that happen at the office?" asked my friend.

I wish I could say I had never experienced a leader or manager who made promises he/she couldn't keep, but I have. It's often a situation where they have less control over a situation than they thought they did, but the result is the same—they've written checks they can't cash.

It's an easy trap to find yourself in if you're not careful. It seems to happen more frequently now than it used to. I wonder if it's the immediate nature of communication generally and our desire to handle issues quickly that causes some managers to almost thoughtlessly write bad checks. I can say, I don't think it's usually an intentional or malicious thing (though sometimes it is).

We had a discussion in our department the other day that offers a good best practice to help keep yourself out of trouble. We were talking about budgets and expense authorizations, but I think it applies to this discussion. Because there are a number in our group who are occasionally on the road and making decisions about the events we're going to attend, the initiatives we're going to pursue and the contracts we're going to sign, it's important to know who is authorized to make commitments, for how much and who isn't. As a project leader, I think it's important to know the answer to the following questions before your start working with a new team:

1. What type of decisions am I able to make regarding the team, resource needs and the project budget?
2. When do I need approval before I make a decision?
3. Is there an established approval process in place?

These are pretty basic questions to be sure, but sometimes we forget to ask them. Knowing the answers ahead of time helps us avoid making decisions and promises today that we don't have the authority to make—helping us avoid writing bad checks tomorrow.

Several years ago my wife's company adopted a communication plan around decisions and initiatives that I thought was very interesting. The language made roles within any particular decision clearly understandable to everyone involved. I think this is a good practice. When a course of action was being discussed regarding an upcoming decision, the parties involved were informed at the outset of their role in the process, that included one or more of the following:

1. You have decision-making power
2. You will be influencing this decision
3. I would like your opinion about this decision
4. I am informing you of this decision

This makes it easy for someone being asked for "an opinion" to understand their role in the process and not misinterpret the invitation for an opinion as decision-making authority. Since this isn't a common practice in most organizations, I will sometimes ask about my role to clarify. It saves me heartburn and helps me avoid making promises I can't keep.

Although this isn't something that happens all the time, making promises you can't keep diminishes your position of trust and inhibits your ability to effectively lead a team. What do you do to avoid making promises you can't keep?

I spent more time at home goofing off than working last week. For Christmas this year, I gave myself some heated riding gear and spent some time in the saddle enjoying the dry weather and  the quiet roads in Utah's western desert. I hadn't been on the motorcycle for a while and it was nice to be back on the bike.

I also spent the better part of this weekend in my garage organizing for a couple of upcoming projects—getting ready for January and February which are usually too cold and wet to ride. I like spending time in the garage. I also like knowing that all my tools are where they're supposed to be when I need them.

I'm looking forward to starting a new year the same way I look forward to riding the motorcycle and working on projects in my garage. I'm not simply hoping for good things to happen this year, I'm setting goals, getting organized and otherwise preparing for a successful 2012. I once had a colleague who set goals and planned every year, but it never seemed to make a difference. Watching him, I noticed it was his unwillingness to roll up his sleeves and get to work. He talked a good game, but when push came to shove, he never got to work.

I talk a lot about empowering the team to participate in the project management process and contribute at a higher level. Most of the people I've worked with over the years responded to the opportunity to contribute to something bigger than themselves, but there are those who just can't seem to get to work regardless of  the environment. Over the weekend, there were things I threw out as I went through my garage—broken grinding wheels, rusted fasteners and other tools that just didn't have it in them anymore. Some of them were easier to throw out than others, but the act of evaluating their value, fixing what could be fixed and making a conscious decision about everything made it easier to map out my personal projects for the year.

I'm not suggesting that the first of the new year is a time to "clean house," but I am suggesting that it's a time to make a conscious evaluation of where your team is—what skills do they have, where are they doing great and where do they need to make improvements? I know it's cliche´but the start of a new year just seems to be a good time for retrospection.

What are you going to do to organize your garage?