Project Management

Project Management 2.0

by
New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog

RSS

Recent Posts

Are You Prepping For The PMP 24/7?

Are You Just Too Darn Busy?

Eliciting Requirements... Creatively!

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

Categories

Advice, Certification, Collaboration Tools, Decision Making, Estimating, Interviews, Learning, Management Approaches, New Templates, Personal Productivity, PM Software, PPM Software, Presentation Tools, Reporting Tools, Requirements Management, Research, Risk Management, Scheduling Software, Security, shameless self promotion, Techie Tools, Time Killers, Time Tracking Software, Training, Virtual Team Tools, Web-based Tools, workshops

Date

Enterprise PPM Best Practices - What's Important?

linkedin twitter facebook Request to reuse this  
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?

Executive Sponsorship
  • Active executive support
  • Establish vision and objective
User Adoption
  • Formalize the user adoption / change program
  • Establish accountability to adoption at all levels in the organization
  • Establish formal incentives or MBOs to encourage desired behavior
    • Time Sheet Compliance
    • Project Performance & Status Reporting Compliance
    • Service Levels
  • Allocate time in each release for end-user prioritized enhancements
  • Use PPM Center data in regular management communications
Training
  • Train the core team before or at the start of implementation
  • Leverage eLearning to reach large user bases
  • Only grant end-user application access when certification is complete
Governance
  • Implement a governance model
  • Establish a standards committee (or more as needed)
Team Structure
  • Treat knowledge transfer as continual vs. a post-project event
  • Build up internal competency as fast as possible
  • Enlist and formalize extended team member roles (w/ key influencers)
Implementation
  • Start simple and manage scope tightly
  • Apply rapid prototyping
  • Consider use of Conference Room Pilots (CRPs)
  • Clearly document landscape of 3rd party integrations and strategy
  • Learn and apply best practices
  • Define a reporting strategy
  • Avoid / minimize customization
  • Design for performance & scalability and reassess periodically
Posted on: August 29, 2008 01:12 PM | Permalink | Comments (5)

Trends in PPM Tool Selection and Implementation

linkedin twitter facebook Request to reuse this  
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.


Driver SaaS In-House
Budget Primary Issue Not a huge constraint
Existing PM and PPM Software Not an investment worth preserving An investment in in-house tools that must be preserved
Existing Skills More in processes, less in existing tools used Large numbers of staff well trained in existing traditional tools
Security Issues Merely desire assurance of security All data must be held in-house
Outsourcing Bent Committed to outsourcing non-core activities or open to it. A we “build what we need” mentality
Need for Speed Need something in place now We can wait
Approach to selection Want to try on a small scale that is easy to roll back from before we do a full roll out We want to be very sure before we commit
Customization We want the standard setup We want extreme customization


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.


Pain Point The Situation The Goal
Supply/Demand Management IT is in a defensive position and “can’t say no”.  Management satisfaction is low because the decision is taken out of their hands. Regulate Demand and make good short-term judgment calls.
Execution Everyone reinvents the wheel with every project and reporting is inconsistent. Repeatable processes and reporting make management easier.
Prioritization
Decisions are made for political reasons or based on very little information. A solid decision-making process.
Posted on: July 18, 2008 03:21 PM | Permalink | Comments (0)

From "Triple Constraint" to "Success Star"?

linkedin twitter facebook Request to reuse this  
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.
  • The "Customer" is the end customer.
  • Business Needs are the ROI, etc. that is easily measurable.
  • Team needs are the needs of the people on the project.
  • Future Needs are impacts that the project will have on the business as a whole, far into the future.
Does this help create a "Focus on the right things" or just an impossible situation?  In this scenario, are "team needs" inappropriately put on an equal footing with business needs?  I know that  "future needs" are hard to quantify and measure, but Aaron's argument is that many critically important projects create a platform for extreme business change.  Maybe that impact won't be felt for years, but if we deliver the project with flexibility, etc. in mind, perhaps we can have a huge impact on long-term ROI.

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?





Posted on: June 09, 2008 12:40 PM | Permalink | Comments (20)

Can You "Create Power" by Focusing on the Big PIcture?

linkedin twitter facebook Request to reuse this  
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?

Posted on: May 24, 2008 03:34 PM | Permalink | Comments (0)

Is the Triple Constraint the WRONG way to Define Success?

linkedin twitter facebook Request to reuse this  
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?
Posted on: May 21, 2008 01:52 PM | Permalink | Comments (41)
ADVERTISEMENTS

"Of all the 36 alternatives, running away is best."

- Chinese Proverb

ADVERTISEMENT

Sponsors