Strategic Project Management

Earlier this morning, I read an interesting article Patrick Gray wrote for TechRepublic titled, Project Management: Death by Deliverables. The idea resonated with me. "A 'deliverable' in it's most noble form advances a business objective of the project or represents a physical output from the project that furthers the company's objectives and delivers monetary value to the organization," writes Gray. "Where deliverables go wrong is when they become disconnected from the actual business objectives of the project and morph into an end in themselves."

Like Gray, I've seen this mentality in many organizations I've worked with. It's easy for some people in the organization to look at deliverables as boxes to be checked. "Box checkers" don't actually provide any value to what they do, they are just going through the motions checking off the appropriate tasks so they can say they are done. Whether or not they provide any value really doesn't matter, the important thing is that the task got done and they get credit doing it.

"Hoards of otherwise intelligent people scramble around leaving a wake of PowerPoints and spreadsheets analyzing deliverable completion rates every which way, focusing all attention on supporting documentation, rather than the end game: a successful project that meets its objectives," continues Gray. "Traditional project management techniques, unless executed flawlessly, tend to shift the focus away from the business objectives of the project as well, chopping the effort into phases and tasks and focusing on completing tasks in sequence rather than completing tasks that will deliver the maximum amount of organizational value."

At first, it might be easy to think, "As long as the project gets done, what does it matter?" Unfortunately, it does matter. When project teams are more concerned with meeting time-lines, it's easy to make short-term decisions that have long-term consequences. Cutting corners to meet deadlines or otherwise focusing on "checking boxes," doesn't serve the project objectives very well. In fact, I doubt that it serves them at all. Project teams should be focused on doing those things that add value to stated business objectives, which is a lot more than simply ticking off tasks as done.

I agree 100% with Gray when he suggests that if you can justify the project as a whole based upon business value, you should be able to do the same thing with its component parts. When project teams and project leadership are focused on delivering business value, as important as time-lines and work breakdown structure may be, projects are successful. A focus on the latter does not guarantee project success.

"Imagine a builder measuring the status of a project to build a house based on tasks rather than value," writes Gray. "He could report impressive sounding statistics like '93% of all nails hammered' and '100% of planning phase completed' without having completed anything that even vaguely resembles a livable house."
 

I have to admit, one of the most rewarding parts of writing this blog is the opportunity to interact with so many smart and dedicated people. We all face many of the same challenges every day and I am blown away by the willingness of everyone I speak with to share ideas, experiences and best practices. Among many of the topics we discuss, the difference between project management and project leadership is a hot topic. Recently I have noticed a recurring theme in some of the questions I get asked, including:

1. How can I actually trust the project team to self-direct their work?
2. What is the best way to keep members of the project team motivated?

Trust the Team

I'll admit that what I'm about to say is probably easier said than done, but worth the effort. I have had the opportunity to work as a team member or a project leader on many teams over the years, and believe that fundamentally people "step up" when given the opportunity. Of course, that doesn't mean that everyone will. In those instances, I think it's important to step back and evaluate whether or not that particular team member should remain on the team. That being said, I recognize that not all project teams have the luxury of picking who's on their teams in the real world, but depending on the organization, they probably have a lot of influence. For any project team to be successful, it's critical to jettison the dead weight that refuses to contribute to the team or doesn't add value. The burden of doing more with less includes doing it with the right people, or projects are doomed from the start.

Motivating Teams

I don't think the argument between the carrot and the stick applies to project teams. Of course, the stick is not a long term solution to motivating anyone. Fear is only a motivator for a short period of time, but is ultimately a credibility destroyer and eventually team members tire of being threatened or insulted, and leave—or worse, they leave mentally but stay physically.

There's also been a lot of discussion in leadership circles about whether or not the carrot really works. I don't think anyone would argue that better compensation is always appreciated, but I know some very well compensated people who are still unhappy in their work.

As a general rule, I believe that people are really driven by a desire to contribute to something bigger than themselves. Let's face it, most of us don't spend our time changing the world, curing cancer or fostering world peace, but there is value to what all of us do. Team members who are allowed to share in the vision and understand how their role contributes to the success of a worthwhile endeavor tend to be engaged and motivated. (And a good compensation package doesn't hurt.)

I don't pretend to have all the answers, these are just my observations and opinions. I am a firm believer in people's desire to do good work. I've worked with very few people who didn't want to be good employees and team members. Please feel free to contribute to the conversation and share your thoughts and ideas.

 

Over the weekend, I read a blog post by Shim Marom, author of the quantumleap blog, titled Projects Failure Rate—The Conventional Wisdom is Wrong! Shim suggests that "...expert reports, published in the last 10-15 years, all of which suggesting that the number of projects failed to meet some sort of criteria is nearing 70%! Got that? 7 out of every 10 projects are a failure..."

Marom suggests that reports like the Chaos Report, OASIG survey, KMPG Canada Survey, the Conference Board Survey, Robbins-Gioia Survey and Dr. Dobb's Journal misrepresent the actual condition of projects. His contention, which I think I agree with, is that we need to come to clearer terms about what project "success" actually means. Although I believe that whether or not a project delivers the specified requirements, is completed on time and on budget are an indication of whether or not a project is successful, I don't think they are only measures of success. In fact, I believe they are an incomplete measure of success.

In my opinion, I'm convinced that the real measure of successful is whether or not the project provides business value to the organization. Now, the definition of value could be measured differently from organization to organization. For some organizations, the success of a project might be measured in terms of ROI gained by income earned with the project, for others it might be money saved or even an increase in the ability to monitor and track processes. (For example, government projects might be less concerned with ROI than they are with governance.)

Whatever business value the project is supposed to provide should be identified and agreed upon before the project begins. If the project fails to provide the identified value, the project failed. This type of measure allows for scope and possible time-line changes, provide they do not negatively impact the projects ability to provide the specified value.

Project leaders that focus on providing business value have a clear measure of whether or not their projects are successful (and this applies to projects that are IT-related and those that are not). As project leaders, we need to start thinking more in terms of business value if we hope to have a lasting and productive project environment. In that sense, Marom is absolutely right, the conventional wisdom is wrong. Let's give the "experts" something else to measure besides time-lines, specifications and budgets.
 

In the real world, formalized projects are only a part of what gets done by the workforce. If we were to take a look at everything project team members do, it would include things such as:

1. Formal projects
2. Ad-hoc requests from colleagues
3. Personal tasks
4. Goals and objectives
5. Repetitive duties that aren't project related

All this work comes from multiple sources, most of which isn't captured in any project management software or other project management tool. If we ever want to get a handle on accurate resource planning, I think we need to look at all the work done by individuals on our project teams. What's more, much of the work that isn't really project related has the potential to be just as important and should probably be evaluated with the same level of scrutiny as project-based work. Otherwise, project managers, team leads, and other project leaders will never gain an accurate understanding of their people's priorities, difficulties, and status.

My team probably spends 30 percent or less of our time working on structured projects of any duration. That's not to say we aren't up to our armpits every day in stuff to do. However, most of it is of short duration and doesn't really require a formalized project plan. It does require prioritization and consideration as to how the work fits with the several different projects we might be working on at any given time. This requires a little creative planning and juggling, but the non-project work we do every day is every bit as important to the business goals and objectives of our organization as the formally planned projects.

What do you do to help your project teams manage their non-project-related work?

 

Wednesday, before the Thanksgiving Holiday, I was reading Elizabeth Harrin's blog post, The 8 Dangers of Implementing Agile. Elizabeth cites the reasons Keith Richards thinks Agile is a bad idea and I found myself disagreeing with every point. Although I don't want to talk about Agile specifically, I think we generally need to take a more flexible approach to project management. Without getting bogged down in the specifics of any particular dogma, I had the biggest disagreement with Richards' arguments in relation to any project management methodology that was different from a top-down, command-and-control approach in favor of a more flexible approach.

I believe what he identifies as big negatives for implementing Agile methodologies are actually wonderful reasons to implement a more flexible approach to managing projects:

1. It arrives bottom up: "This bottom up stuff is a bit dangerous," says Richards. I couldn't disagree more. The people closest to the work understand it the best. Who better to provide input into processes than those who work with it every day? I don't think that a successful methodology that grows throughout the organization is necessarily a bad thing.
2. It looks simple: "If it was simple we wouldn't need to be trained up in PRINCE2," says Richards. Whether it's PRINCE2, the PMP, Certified SCRUM Master, or any other certification, if the only argument to making the process complicated is so that those certifications have meaning, then the certifications have lost all meaning. I think Einstein said, "Any intelligent fool can make things bigger and more complex... It takes a touch of genius—and a lot of courage to move in the opposite direction." We should not be afraid of simplicity. In fact, I've found that the simplest solution for any situation is often the best.
3. It's mixing oil with water: According to Richards, Agile has a particular approach to governance that doesn't sit well with some heavy corporate governance structures. Although that is probably true, not every project-based organization has a heavy corporate governance structure. I agree that there are times when a hard-core waterfall approach to managing projects is appropriate. However, that doesn't mean that every project should be managed that way; and what's more, I believe there is a problem with a one-size-fits-all approach to managing all projects. As project managers, I wonder if it's time for us to step away from a rigid adherence to any particular dogma and embrace the simplest solution to solving the particular needs of every project. We should be thinking in terms of project value, not a dogmatic faith in any particular method.
4. You start with timeboxing: I look at timeboxing as a simple way to actually do some real resource planning. I also think that most projects would benefit from taking projects and putting them into smaller, achievable chunks. I'm a firm believer in demonstrating value regularly and often. If timeboxing does that, I see it as a benefit. Richards suggests an education campaign and really understanding what you are setting out to do. I agree 100 percent with defining objectives and really understanding what you are setting out to do, however, making the determination that projects will be within a certain timebox, doesn't stop you from doing so.
5. Teams self-manage: "Who's going to pull things together?" Keith asks. A command-and-control management style is not an effective way to manage anyone. It hasn't been for the 30 plus years I've been in the workforce, and it is even less so now. That doesn't mean that there isn't a single point of contact. Whether you are a scrumaster or project manager, your role is to facilitate collaboration, remove impediments, and lead the team. We should focus more on being a project leader, rather than a drill sergeant.
6. It grows virally: "Don't let Agile spread virally," Keith warned. I wonder if the fear of a lack of control is really the issue here. The viral spread of Agile, it could be argued, is an indication that in many circumstances, it must be working. Of course that doesn't imply that caution should be thrown to the wind or that a willy-nilly approach to how we manage projects is appropriate. However, as project leaders, we should be thinking in terms of what methods will work the best for the team to help facilitate a productive project environment. Viral isn't necessarily bad.
7. The people upstairs don't get it: Elizabeth suggests that this is a danger for any methodology, and she is right. That being said, at the end of the day if your project management approach is delivering value, a positive ROI, and successful projects, does it really matter if the people upstairs get it? They aren't working on the project team. They want projects to demonstrate value and return. Don't believe me? Try going through a Gantt chart and resource grid with the executive team and time how long it is before they are fumbling with their iPhones, looking at emails, or worse—have you excused from the meeting.
8. The tools drive the transition: I agree that tools should support any new process, not the other way around. I also agree with Elizabeth when she points out that this is a potential problem for any project management methodology.

I guess the long and short of it all is that Mr. Richards' arguments appear to be a throwback to a command-and-control philosophy that doesn't fit with the needs of today's organizations or the way project teams work. There is a place for Agile and more traditional project management approaches. Which approach you use and when should be determined by the needs of the project and not by the bias of the project manager.

Have I missed the boat?