Bare Bones Project Management was supposed to be nothing more than a lightweight summary of standard project management practice. A few years and several hundred seminar participants later, it turns out that it is, in fact, more than that. Unlike traditional IT project management it asks project managers and project teams to take responsibility, not only for completing projects, but for their success as well.
Who knew that would be controversial.
Professional project managers understand that completing even the simplest project is hard, and the job only gets more difficult from there. So as a matter of survival, they develop a laser-like focus on making sure their teams finish all deliverables on time and within the project budget.
The Bare Bones methodology asks for more. In addition to managing budget, duration and deliverables it also recommends project managers insist on clarity with respect to:
- What “major goods” – increased revenue, decreased cost or better-managed risk – the project will contribute to, and how.
- What success looks like … not just completion, but business success.
- What will change in the business to make success happen (the project’s goals).
This approach leads to two challenges, one practical, the other philosophical.
Practical things first: Accept the above and you accept that a project’s goals and deliverables must each be complete. In properly defined projects, if you achieve all of the goals you must achieve the revenue, cost and/or risk objectives that are the point of the project.
And, in properly defined projects (or multi-project initiatives), if you provide all promised deliverables then you must achieve all of the goals.
To illustrate, imagine you’re managing a project whose ostensible purpose is to install the supply chain module of your company’s ERP suite. In most companies the project team would limit its role to implementing the module and configuring it so it meets all business requirements. Do that and the project will have been successful.
Except that it won’t have been successful. Complete? Sure. But no business benefit happened, and according to the usual methodologies, that’s Someone Else’s Problem.
Bare Bones starts with the point of it all. Supply chain projects, for example, usually contribute to the bottom line by reducing costs, and secondarily by managing risk, reducing both the likelihood of supply-chain interruptions and their impact should they occur.
Project goals (business changes) come next, and implementing the software is one, but hardly the only one. The test of the goals is that if you achieve them all then the business benefit must show up. Implemented software doesn’t get you there by itself. Quite a few other business changes have to take place:
- The supply chain must be managed according to modified or altogether changed processes.
- Employees must take on different roles based on the modified processes.
- Employees must become competent to perform their new roles, which is different from their knowing how to operate the new software.
- Very likely, the compensation structure must change to eliminate “perverse incentives” that will drive managers to subtly sabotage the change effort.
- Possibly the old organizational structure will prove incompatible with the new processes and require changing as well.
If these aren’t all defined as goals – either of the project or, better, of a collection of small, closely linked projects – then the effort will fail, even if it “successfully” completes according to the scope/budget/schedule formula.
With this set of project goals it’s clear the list of deliverable must be expanded as well: Software (and documentation) won’t do the job without new process designs, a training plan, new position descriptions, compensation surveys and recommendations, a new organizational chart, and a business change management plan.
Sound intimidating? It should. Business change is never easy.
But if you’re tempted to waive this off, preferring the old methods where everything except the software is Someone Else’s Problem, consider this:
When business change and bottom-line benefit don’t end up happening, who do you think will receive the blame? The business department that failed to implement new processes?
Or you as project manager, for “delivering software that doesn’t solve our problems”?
I’d advise taking responsibility for project success as well as completion, even though you lack the commensurate authority.
Which is the philosophical problem mentioned earlier: Authority is supposed to accompany responsibility. It’s a lovely philosophy, easily applied to all situations except those that involve getting something important done.
If you disagree, consider Sales. Sales representatives have no authority over their customers.
Think that lets them off the hook?
Bob:
While I agree with your premise and in a perfect corporate world your premise is extremely solid and should be used.
However from my (somewhat tainted) point of view the practice does not come close to reality.
Example a small (say $100K) project was proposed and a team was formed and a consultant hired to a proposal.
The project was a short lived one it was estimated about 4 weeks. All the people contributed to the project and it was done in a reasonably quick 5 weeks.
The proposal was written up and I went through it line by line and could not see any errors. Then the group that (it was written for) got a hold of it and they liked it so we submitted it to the board. Then the politics began and after a few meetings which got more and more tense as each meeting was held. The end user was furious (not about the dollar amount) but because the language in the proposal used the British spelling of 2 or 3 words. I was absolutely flabbergasted that anyone would even care. The user group went to the board and said no to the proposal. Management(ours) still wanted it so we spent $125K and hired a outsider (and a half). The outsider came in and he looked at our proposal and asked what was wrong with it. We did our best to explain the politics of the issue. It took him 1 week and he redid some numbers (same bottom line) and produced another proposal.
This time I found a English Major(that cost us $5000) and she essentially proof read it. The second report) and came up with 2 or 3 words that either were changed or were broken into separate sentences. I asked her to look at the original to see if we were off the mark and she said it was fine she would change the spelling of 2 words but other than that it was fine.
We turned the proposal into the board (again) and this time the users went on about something else (again they didn’t want the money to come out of their pockets). They turned it down as costing to much. We had a couple of meetings where they were shown the cost and agreed that 100K was right on the money and that did not make a bit of difference.
They came up with some what if’s that were not even in their radar in the first proposal.
I finally asked for a meeting with the department head where only the two of us were present and I went over the numbers and the other items in the proposal and he admitted that the money was right but they didn’t like the proposal coming from the IT area and said if anything it should come from their area. I shook my head and said look if you want to take our name off of it and put their name on we would be happy.
I walked out of the meeting in disgust I do not know how many hours I had worked on it but if it made the user happy fine. I talked with my boss and he said he wasn’t surprised. I almost blew my head off as he didn’t bother to tell us we were stepping on their toes. I was thoroughly disenchanted with the company after that. I went out and two weeks later found another job. IIn my exit interview I had a chat with the CEO and appraised him of what was going on and why I was leaving. He was not too surprised. I was never so happy to leave a company in my life.
Ed
You make an excellent point concerning Sales representatives lack of authority over their customers. Could this be why many successful C-level people were originally successful Sales representatives? They developed and refined the right skill set for their new positions?
Long ago while discussing a difficult problem, a wise boss said, “You may not control it, or have direct responsibility for it, but I expect you to exert STRONG INFLUENCE on the situation.”
He meant FIX THE PROBLEM.
I said “OK” and began my growth from a manager to a leader and executive positions.
After each of my ERP projects, I stayed on to run the supply chain.
Too bad many won’t take responsibility for results even in their own span of influence.
Witness banks, automakers… Let alone an ERP project.
I recommend Bare Bones as often as I can (even to non-IT people) – the responsibility imperative is just one of many reasons I found it the best project management book I’ve seen.
Like Lee and Dave, I’ve drunk the kool-aid. I apply/pimp Bare Bones PM for all sorts of non-IT applications because it moves me beyond the simple engineering question of “how” (“How do we do this?”) to the more important question of “why” (“Why are we doing this?”). Until we can answer that second “why” question in some detail, any work my team does on the “how” question will be doomed to disappoint.
Obviously every business problem or challenge involves many different interactions and processes (including many non-IT processes). A successful project will be one that has teased all of these threads apart, identified where the bottelnecks and opportunities lie, and addressed them accordingly.
Unfortunately, busy business unit managers in the heat of battle (many of whom aren’t systems thinkers by trade or inclination) don’t have the time, perspective, or skill set required to do this sort of analysis. In lieu of identifying and fixing their real issues, the hope that IT solutions will be able to improve their performance by virtue of sheer horespower has a strong appeal.
From where I sit, this dynamic drives the tendency to view IT on the “internal customer” model: “My department is broken… you smart guys sell me something that will fix it.” For the Business Unit Manager, this retail approach has the added advantages of:
– Not having to use one’s own capital to examine and repair one’s own business processes
– Having the ability to blame the IT “seller” when the “purchased” project doesn’t actually improve performance in a way that justifies the expense.
Then again, we in IT have our own reasons for standing behind our metaphorical deli counter waiting for the various business units to ask us for a pound and a half of something. One one level it makes our job a lot easier if we don’t concern ourselves with what they’re trying to cook. All we have to worry about is filling the order: slice it, weigh it, wrap it and deliver it. What’s more, we like maintaining a little “plausible deniablility” ourselves: The less we know about the ultimate intention, the better we’ll be able to plead ignorance when our “customer” realizes that maybe black forest ham didn’t actually go all that well in their chocolate chip cookies.
Of course,”ability to plead ignorance” isn’t exactly a big value-add you can point to proudly at budget (or review) time.
This “responsibility imperative” is what makes Bare Bones work well for me. For real results to be achieved that serious big-picture business process analysis work (that nobody else wants to invest themeselves in) has to get done. I can ignore all the bits but my own and hope to survive the Mexican standoff of fingerpointing afterward, or I can be the guy who actually steps out of IT-land a bit and makes the connections neccessary to deliver something useful (not just something under budget and on time).
This may sound like a lot of extra work and hassle, but in practice I’ve found that the time we invest in this way is more than offset by the “project triage” that results: When working with business units to understand why their existing processes aren’t currently meeting expectations, it’s not uncommon to discover that the easiest, most cost effective changes are not neccessarily the ones they thought they wanted when they came to you looking for that pound of ham. The best “fixes” often turn out to be not even IT-related, so the result of the working the “project” in this way is frequently “no project at all”. Not only does this keep my slate clean to provide better service on the projects that do end up in an IT queue, but it also allows me to burnish my rep as a invaluable member of the team even as I avoid the extra work.
As a career strategy, this beats the heck out of “maintaining plausible deniability”.