Lowering Your Altitude: Where does BPM Start?

At the top level, the decision was made to go forward and a general plan of how things would work. There was not a lot of visibility into the way things worked at the bits and bytes level, just the Big Plan. Which is exactly how it should be. At the technical level, the technical folks had already decided how the bits and bytes were going to work and had a couple of Visio diagrams and a to-do list on a spreadsheet. Which, for most inside-the-company, lets-go-do-it-jobs, is exactly as it should be.

As an old hand who has been around the block a few times, I started asking questions: Where's your business process model? Where are the sequence diagrams? Where's the ERD for the existing data?

At the top level, this seems like kind of running off in the weeds. A lot of pictures? What do we need that for? At the bottom level it seems like a useless layer of management: hey, we've already specified the system, what do we need all of that paperwork for?

The ironic part is that everyone is correct. The flaw is in thinking there is "one system" that is being specified. Things look different at different levels.

I see this all the time in really big companies. What looks great in the board room is blown off by the time it gets to the trenches. But they usually have the money to do the middle pieces. Usually this is called the program office, the project office, the management board - -they have a lot of names. At the project level, any good PM will ask these middle-tier questions before committing resources: it's just common sense. I've consulted in all sorts of environments, and unless I know how my piece is structured and behaves, I don't start working. That's just the way good teams work.

The interesting question is at what point do you start thinking about that middle piece? If you're a dot-com start-up like Dzone, everybody is a developer and you are not having a business discussion without having a technical one at the same time. If you are a brick-and-mortar business with less than a hundred employees, everybody knows everybody and the technical and the strategic mix freely. But when do you start thinking in terms of strategy? At what point do you say "This is the model for the way we run the business, and we will plan and execute around it"

If you ask the big guys (on a honest day), they will tell you the horse is already out of the barn -- that strategic mapping and BPM has to operate tactically. If you ask the little guys, they will tell you that there is no barn -- the strategy is the work. There is no cost-benefit for abstracting what we do. The truly sad and ironic thing about all of this is that if you ask the management consultants (the real ones, not the pointy-headed reality-challenged ones) they'll tell you that you always need it. You always need an abstract picture of where you are and where you are going.

In real life, successful companies structure their projects and determine those parts of the business model they are operating in before beginning. The professional middle-tier of most larger organizations know they need this and are spending a lot of money to get there. But the little guys aren't so sure (or don't understand the question), and the top of the large companies are uninformed. Sure they know what they read in CIO, but that's like saying I'm a master fisherman because every now and then I surf pass the fishing channel on the way to the History Channel.

I think the key is that you have to be able to change your altitude. What looks good at 50-thousand feet might also look good at 10-thousand feet, or it might have some bumps. At one-hundred feet it might be downright ugly. You don't know. Whatever your level of work, I think you have to be able to move up and down a notch in the organization and see how it looks from there. That means that C-level executives should have knowledge of running a PMO. Your PMO managers had better be able to run good projects, and your Project Managers had better know the technical details of what the project is. It works the other way too -- if you are a programmer, you should know your way around a software methodology and a project plan. If you are a project manager, you'd better have some ideas about program management: gateway, prioritization, portfolio balancing, structured tagging, FPA. If you are working in a PMO, you'd better know something about how the ship is running and where it's going. Finally the C-level guys had better be tight with the board of directors and stockholders.

By the time we reach the C-level, we get really good at "managing up" and "managing down" We're maybe not so good at being able to change our altitude. At the bottom level of the organization, nobody knows or cares most of the time.

They should.

If you want to make more money, you have to step back and evaluate where you are and change yourself. This is true of people and it's true of businesses too.