Enterprise PPM Best Practices - What's Important?
Situation: You are coming up on a PPM implementation and want to focus your efforts.![]() We recently spoke with the folks at HP who have very significant experience and tools with some of the largest scale PPM efforts out there. A quick look at some of the analyst reports will show you the scale that they work on, which is complex and often high risk. They were kind enough to share the following list of best practices with us. I'll give you the list and share some of my personal opinions on the topic. I'd certainly love to hear yours as well. A list like this can be dry to those who haven't experienced the importance of some of these things first hand. The war stories are what make them come alive - so please share them. My personal pick of these is under team structure. I think that most PPM implementations fail because they lack ongoing commitment - a long range plan and most importantly PEOPLE that will see it through long-term. Organizations often invest heavily in tools and up front implementation, but resist investments in the people who can really make it all work. Tools only facilitate these sorts of solutions. People make it happen. What's your pet best practice in PPM?
|
Trends in PPM Tool Selection and Implementation
| Situation: You are thinking about how PPM fits at your org... I recently spoke with Demian Entrekin, CTO of Innotas about the trends his organization is seeing in the marketplace. Although every tool vendor obviously has an angle to sell, Demian isn’t your typical product pusher. Together we worked through what's going on now (at a high level) as more companies take on serious PPM efforts. Hopefully this will be helpful if you're in one of those companies where PPM is a promising new approach or you're giving it a second try after a lackluster first effort. SaaS vs In-house Implementations A key choice up front in the selection process is whether your organization is biased toward SaaS or in-house solution. Take a look at each of the drivers listed and see which way our company inherently leans. Some say that people don't change. The same sometimes holds true for companies. So this table could give you a real view into the future. Based on our conversation, here are some key drivers.
This is, of course, just a high-level review of selection criteria. Hopefully enough to “get smart” quickly as you begin your search. If you want a more detailed look at selection criteria, take a look at the selection tool published on Projects@Work. Who Feels Your Pain? Demian tells me they see three basic problems (pain points) when they approach a new customer. They try to focus on ONE at a time. If you think about the pain points in the chart below, it’s very much a question of maturity. It's likely that the success of your first efforts will depend not on having project prioritized right away, but on achieving that next level of maturity. So as you look at tools, think about the maturity of your organization and how well each candidate tool will support your efforts in that next critical area. This applies not just to the tool itself, but to the services and best practices that come with it. Many of these efforts are half tool and half process. As you narrow your search, map out how you will tackle each pain point and think about which has the greatest chances for success.
|
From "Triple Constraint" to "Success Star"?
| Situation: You want to be help define something new... I had a terrific response to my Triple Constraint posting week before last. So I thought I would take it one step further this week based on your comments. If possible, I'd like to see if it makes sense to collectively create something new. If it's a bad idea, that's fine - just let me know what you think. Fully realizing that the PMBOK Guide does not put the Triple Constraint out there as the measure for success on a project, I was trying to address the reality (and Aaron Shenhar's) position - that it's very often used that way. To me it's a problem when PMs get so FOCUSED on the Triple Constraint, that they make mistakes in the delivery of their project in the name of "technical success". I got a long string of comments back that expressed a range of opinions and it made me think that it might be productive to take a look at a couple of potential "success stars" - a quintuple constraint if you will, that we could actually use to define the success of a project. ![]() If you look at Figure 1, I've used Shenhar's five success criteria as the points on the star, meaning these are the five things that must be balanced in order to have a successful project. Remember the triple constraint elements are all captured in the "efficiency" point here. So the "technical" success of the project is just one element among five you need to be aware of.
In some you comments, I felt like the was the feeling that the triple constraint was good, but it was missing a "business value" or "business needs" point. I believe some said that "quality" could be too defect focused and didn't necessarily capture all of the business impacts, the ROI, the strategic impact at a given point in time, future needs, etc. So I threw together the version in Figure 2, simply moving quality out to a point and adding business needs as another. I'm not saying this is a solution and one argument against it is obvious - since the new elements can be generally quantified in terms of cost, they are not valid as separate "constraints". They don't have the same direct "push/pull" going on that the triple constraint has. You could also argue that future needs (whatever requirements they generate) should be part of scope, but then so could requirements related to quality.At any rate, my point was not to say, "here are two solutions - pick one", but rather to generate some interesting conversation. If you accept that the triple constraint is overused as success criteria - what would be better? |
Can You "Create Power" by Focusing on the Big PIcture?
Situation: You want to be more influential in your PM role. In my last posting, I discussed the Triple Constraint and whether its a good success standard or even a good focal point for project managers today. In this posting, I wanted to touch on a follow-on concept that Aaron Shenhar described in his PMI Chapter presentation. He said that "Project Managers have a terrific opportunity to Create Power by focusing on higher level issues versus technical project success". PM as Strategist He said that if PMs focus on creating competitive advantage by thoroughly understanding that aspect of the project and keeping the project focused on achieving that advantage - they are more likely to acheive real success. PM as Visionary He also said that "spirit" is important in that the PM must create excitement by articulating a clear view of the future - effectively a "project vision". I would say that to put this into action you need: - To be sure your project is a "competitive advantage" project. - To have your head high enough above the weeds to clearly see the big picture and completely understand the competitive advantage. (Investing a significant amount of time with upper management both in the beginning and throughout the project. - Ensure you have the right sponsor. What other things are key to making this work? |
Is the Triple Constraint the WRONG way to Define Success?
| Situation: You want to take a broader view of managing projects. My new favorite author spoke at our local PMI chapter meeting last night. Aaron Shenhar's book, Reinventing Project Management gives you a LOT of food for thought, but I think that one of his points is truly a breakthrough concept in our field. It cuts to the core of why there is so much controversy around PMBOK-based approaches and Agile approaches. In his presentation, given mostly to PMPs mind you, he says, "PMI has given us a great foundation. However, it's time to leave that foundation and go to the next level." During his talk, he described a number of reasons why the standard approach to projects must change. A lot of it sounded rather "Agile" in nature. For instance, he talked about the Triple Constraint theory as being a key impediment to successfully delivering projects - because it incorrectly defines the success criteria. He said, success should not be defined just in terms of Scope, Cost, and Time - which are strictly efficiency-based. The focus should be more on business results and customer satisfaction.His definition of success is broken down into the following categories: - Efficiency (criteria similar to the triple constraint) - Customer (criteria = customer satisfiers) - Team (criteria = customer satisfiers) - Business Needs (criteria = things like ROI, strategic fit, and competitive advantage) - Future Needs (criteria = future value, like in the case of new technology where much of the value is yet to be defined) His theory (he describes it as 'project manager as mini-CEO') is "If you approach projects with this broader set of success criteria, you will be a better project manager, because the results will be better." It's hard to argue with that. It feels to me like he is calling for us to combine what PMI is starting to address separately as leadership skills with the PM approach in general. How do you define project success? If the Triple Constraint good the way it is or should some of these higher level issues always be considered when managing projects? |








In some you comments, I felt like the was the feeling that the triple constraint was good, but it was missing a "business value" or "business needs" point. I believe some said that "quality" could be too defect focused and didn't necessarily capture all of the business impacts, the ROI, the strategic impact at a given point in time, future needs, etc. So I threw together the version in Figure 2, simply moving quality out to a point and adding business needs as another. I'm not saying this is a solution and one argument against it is obvious -
In my
During his talk, he described a number of reasons why the standard approach to projects must change. A lot of it sounded rather "Agile" in nature. For instance, he talked about the Triple Constraint theory as being a key impediment to successfully delivering projects - because it incorrectly defines the success criteria. He said, success should not be defined just in terms of Scope, Cost, and Time - which are strictly efficiency-based. The focus should be more on business results and customer satisfaction.