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

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)

Scrappy Project Management

linkedin twitter facebook Request to reuse this  
Situation: You're tired of guiding new PMs with templates.

Kim Wiefling is a scrappy project manager - no doubt about it.  Whether you're listening to a voice mail from her, reading an email she sent, or browsing through her book.  She's the kind of person that calls it like it is - and that's what I like about her book, Scrappy Project Management.

It's not about templates or process (not that I have anything against those).  Each chapter focuses on a rookie mistake that every new PM makes before they have enough experience to set them straight.  Here's a list of the chapter titles:
  1. Customer, what customer?
  2. If you don't know where you're going, any road will do.
  3. Communication, we've got real work to do!
  4. Hey, it wasn't me, it was the "others".
  5. Why plan, let's just get moving.
  6. Risk? What could possibly go wrong?
  7. Priority?  Everything is #1!
  8. Change?  What do you mean things have changed?
  9. Assumption is a mother.
  10. So, what were you expecting?
  11. Lessons not learned.
  12. Sure we appreciate you - didn't you get your paycheck?
These are mistakes we all made early in our careers - and continue to watch others make every day.  Trying to correct them is tough - like trying to give your kid the benefit of your experience.  However, if you see someone struggling with any one of these things - it might be a great time to hand them this book (properly marked) and walk away. 

I know, I know - but it's worth a shot...
Posted on: May 12, 2008 05:17 PM | Permalink | Comments (1)
ADVERTISEMENTS

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

- Howard Aiken

ADVERTISEMENT

Sponsors