Many will say their Project Management Office (PMO) has been established to promote “Best Practices for Project Management” – better work product, alignment with business strategic direction, etc. That may be partially true, but let’s inject a little reality here … many PMOs were created to help solve what I call the Dirt Bag problem – you can’t fit 10 lbs of “dirt” in a 5 lb bag.
I’m talking about the project prioritization process; I have 100 different project requests, but only time and resources to work on the top 20. How do I rank order so many? And how do I make sure I’m working on the right thing for the business? These conversations are always quite interesting, and it typically takes a certain amount of gamesmanship to get your project closer to the top of the list.
And here’s the sad (but unfortunately true) significant driver of interest in this game. It’s not about getting your project on the short list – people typically will do whatever it takes to avoid the tough conversation and tell someone in the bottom 80 that their project, however worthy they might think it to be, will not get started for a while.
No one [in IT] likes to tell the business “No”
Maybe next I’ll write about how to win this game … but first I want to talk about how to cheat.
<aside> Come on, it’s Friday evening and I’m just having some fun. That might be too strong a word, but it got your attention … </aside>
I call it cheating because it’s really a way to avoid the tough conversation. No one likes to disappoint their business area, and so everyone rails against the lack of fairness / transparency in the prioritization process. However, more often than not it’s the way projects / solutions are designed and delivered that gives the appearance of over-engineering, needless methodology bureaucracy, and a general lack of agility. Time-to-value is a significant driver of perception – it’s the same concept that drives
- agile software developers to create multiple incremental builds
- lean manufacturing advocates to drive down inventories and reduce cycle time
- BI vendors to tout real-time analytics
- supply chain designers to speak of mass customization
We can leverage [ie. blatantly copy] ideas from these various disciplines to help us cheat at the prioritization game in three significant ways:
Scope: “Pareto” the requirements – can you do 20% of the work to get 80% of the benefits?
- Establish a benchmark that no projects can go over 90 days. This breaks down larger chunks of work, making it easier to fit things into a schedule. It also …
- … reinforces the idea of incremental deliverables and shorter time-to-value
- … provides natural break points, so efforts that would take six to nine months are split into staged deliverables with built-in pauses (facilitating change management while allowing other projects a turn at the resources)
- Start with Requirements, not Solutions. Don’t tell me what you want, tell me what you need. You may be asking me for a high-powered intranet dashboard with 8-10 timely KPIs represented with flickering lights and fancy AJAX meters, but that’s an awful lot of interesting (ie. complex, expensive, and buggy) new software components. Would you be better served with a simple e-mail that automatically appeared in your inbox every morning, prominently showing the five critical numbers needed to run your businessfor
the day? - Start with Solutions, not Requirements. Yes I know I just told you not to jump to a solution, but a technically adept and experienced solution developer should have some kind of an idea of what the finished product will look like, and/or what it will take to deliver what folks are really asking for.
- You could let them “blue sky” their way towards a do-it-all architecture that will take 12 person-months of effort to deliver
- (or) You could describe for them a simple solution built with fast delivery, easy to support, already-exists-in-my-data-center technologies that could be delivered in two months
Speed: Reduce your cycle time! Develop and streamline your project design, delivery and management processes.
- Develop and iterate on Standard Work – and stick to these processes with no exceptions.
- Create, refine and reuse Templates for all major project deliverables. The Project Charter is the first critical deliverable – but it could and should be a fill-in-the-blanks affair if you have a decent template to start with.
- Simplify – eliminate non-value-adding steps in the delivery process. Do you really need to invite every single project member to a group reading of the weekly project status report? Can’t you just send an e-mail or (better) start a project blog?
- Streamline supporting processes. Get procurement or legal or whoever to pre-approve technology partners. Use templates (again!) to create statements of work, user ID requests, or building passes that can get approved immediately with no additional review.
Transparency: Pre-empt any crankiness about projects that never get started, or projects that never make it to the top 20, by providing clear and simple information about all projects.
- Looking Back: Quantify the number of projects and successes delivered over the last six to 12 months. (This is a nice way of saying Don’t say I never gave you anything …)
- Looking Forward: Deliver a “pipeline” report, what are the other projects on IT’s radar screen, and why do they have a better business value than mine?
By simplifying the project requests, delivering them quickly, and providing full visibility, I can stack the deck in favor of prioritizing my projects, and soften up the folks who will have to wait. Kind of sneaky, yes?
This Post Has 0 Comments