When is a project a Project? How to prevent the buildup of backlogged requests
I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.
I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.
Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...
- Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!
- If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.
- Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
- Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that little something extra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.
- Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.
- The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)
Previously ...
- End-around the Prioritization Process (August 14, 2004)
- Pendulum swings - Santayana says ... (May 12, 2005)
- Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
- Open Source as bargaining chip - driving business value of IT (October 30, 2005)
- Of course we can pay for that ... if it makes business sense (November 7, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- The "Army Rangers" model for IT Professionals (January 2, 2006)
- No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
- Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
- Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
- Defining the Business Value of a Project (October 25, 2007)
- PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
- How to Cheat at the PMO Prioritization Game (December 14, 2007)
- How to Win at the PMO Prioritization Game (December 18, 2007)
- Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Technorati Tags: business value of IT, PMO, project management,
Labels: business value of IT, PMO, project management
posted by James P. MacLennan at 11:07 PM
| Permalink
| 0 Comments
