Comments on: Overheard: Who should the PMO report to?

By: Bob Turek

Bob Turek — Wed, 09 Jan 2008 17:25:54 +0000

Margaret- now you’ve got me thinking. I’ve been on the sales/project scoping side and the delivery side of projects. In selling and scoping my initial goal is to understand the client’s challenges in their terms and language. I try to resist the temptation to begin defining solutions until we have a solid agreement on what the problem is. Thereafter, as much as makes sense, the solution, and more importantly the value, should be in their language. There is obviously a point where new terminology/concepts/approaches need to be introduced- the more we understand the business, industry, and the problems the better we will be at developing a conversation with common language to introduce these. This up front work and emphasis smooths out a lot of bumps in the road. Easier said than done because of all the temptations and distractions along the way.

By: MargaretRouse

MargaretRouse — Wed, 09 Jan 2008 16:11:12 +0000

And I’m going to think more about how language remains a barrier to effective communication when the business owner is trying to articulate what they need to developers and the developers speak Agile. Thanks!

By: Bob Turek

Bob Turek — Wed, 09 Jan 2008 01:02:45 +0000

Margaret- I’ve already got your site in my favorites because it looks interesting and you are one of the few who seem to post regularly.

As to PMO and agile- I’m much less of an agile software development guy than a PMO person. You taught me a couple of things already! Project Management Office or, for smaller firms, some type of project control function, succeeds with excellent business processes for project visibility, strategy alignment, and prioritization (to name a few).

My guess is that the “mythical” queue is bloated because a project inventory isn’t done regularly and many projects are not aligned with strategies. These two things would decrease the amount of, and focus, projects. Lack of prioritization criteria and working the priorities as strategies change contributes to “bad” muti-tasking (stop, restart, relearn). You end up with a mess that allows people to move from project to project without accountability and very bad estimating. The PMO should be doing the type of support to standardize visibility, strategy alignment, and prioritization processes plus does everything it can to help projects accelerate. All of this is largely “outside” whatever software development process is used, as it should be. This is a good conversation- I’ll be posting on it.

By: MargaretRouse

MargaretRouse — Wed, 09 Jan 2008 00:11:42 +0000

You’re most welcome. You really got me thinking!

I think what REALLY blew me away was when you said that 74% of all projects fail — and that the number could be even higher for IT projects. I’m interested in any concrete strategies you can offer for avoiding getting small projects lost in what we used to call the mythical queue.

I’m also interested in learning how to communicate more effectively. Can you teach us how to speak PMO? There are so many specialized words in Agile development — take “story” for instance. It’s not a natural thing to know that a story is a business need, or how a spike relates to a story. It’s a whole language I didn’t even know existed until last Spring.

By: Bob Turek

Bob Turek — Tue, 08 Jan 2008 19:03:34 +0000

Margaret- thanks for the link. That same pain that drives creation of a PMO can be it’s undoing: PMOs are often eliminated after the pain goes away. The pain also tends to create a PMO that is monitoring/cost based instead of value based- i.e., focusing on the value that can be created by projects vs. merely working to a budget. The value based PMOs tend to spur innovation and have projects aligned with strategies. I would appreciate your insights and comments on what you are interested in. I’ll take a look at your posts.