cognoise

Why the PMO is dead, done and dusted?

Lets look at some core functions of the PMO and how it is dead, and why they will continue to be irrelevant.

1. Major responsibility that I did when in an IBM PMO was review of a bunch of projects. Review of progress is not so useful in the world of constant communication, low planning and high coordination. Primarily because there will always be a delay to this reporting and whatever form of output, will not be fresh or add to current decisions and progress. Only being engaged constantly, in-situ works esp in the complex/emergent and chaotic/novel domains.

2. Second job within the PMO was demand and intake management. As I see today, the central IT departments are so warped in their own cocoon of legacy processes and structures, their client business departments are fortunately free with their own IT budgets and prefer to go independent.

Thus leaving the IT department only with some of the following that are stuck in a different age tenet.

  • GRC, ERP, finance, other corporate systems, stuck in the records era
  • providing infrastructure that is already commodity, stuck in the pre-cloud era
  • or licensing of standard software, stuck in the PC/pre-mobile era

For example take document storage, editing and collaboration, in the age of dropbox and google docs, when all we get within the company is a PC age MS Word to be sent over email or uploaded in a sharepoint, all these were the IT department’s independent decisions. Take connectivity or storage, with  at least 2 mobile devices per head that have better connectivity and also employee’s overall personal storage leads the standard enterprise storage with poor connectivity. OK those for another post.

Point I am trying to make is the legacy standard processes have lived their life (and dead now) to be managed from the PMO. Recently I was filling a paper form for deploying a mobile application internally, and I realized this in a worst possible way waiting for some PMO to review this and get back on the request. Surely their demand management processes are outdated and responsibilities have shifted elsewhere which is business itself.

3. When business departments have gone independent, it makes it clear for them to track accountability for their investment not some un-translatable set of IT metrics that the PMO tracks. At least through my career, I have seen so many promotions inside the IT department, because of this lack of clear metrics, that even a failed business outcome project could be a grand success IT project.

If the PMO was to be even marginally useful, only way is actually play/perform, not review/report…

Advertisements
Standard
cognoise

Project Artifact as Boundary Object

A project can be visualized as a opportunity for interfusion of multiple different identities of people. These identities stem from role performed in the project, technology specialization/association of the project team member, affiliation with customer through proximity on location/role/relations, among many other identities.

A general agreement to collaborate across these different roles is realized as a need in most cases and there are contractual tie ups (could be a real agreement, or defined by role and individual responsibilities) between several pairs of parties, customer-service provider, manager-resource, practice-resource, onsite-offshore. Real progress on work usually involves actions by project team members across different identities.

When identities fuse across, there is a need for objects that are “Common Point of Reference that can have different meanings attached to it, while can act as a means for coordination, alignment and translation, while catering to different concerns simultaneously” 

That was a definition of Boundary Object, all emphasis indicate the key characteristics.

Within Knowledge Management there are real good examples of boundary objects, below are some

  1. wiki page on wikipedia
  2. Knowledge Map of a project/community
  3. a story/anecdote

 If you are on a project it is likely that your deliverable, usually an artifact is also being used as a boundary object. But no one thought about it that way yet…and you compromised, some symptoms below

  1. Have you ever noticed the indifference with which core process groups fill out or create templates, while the end users of the templates find it hard to use it for any real purpose
  2. Even when you send a status report that goes through the hierarchy will the “head” be able to make sense of the original concern that you wanted to be acted on or was it all lost in translation
  3. Dev team seems to be at ease with the seemingly random project wiki, while the business team finds it real hard to get anything out or the other way around, is the wiki really that pliable
  4. The tester does not seem to be all concerned with the reds in the project plan, while the PM is unable to catch the significance of a red flag in a key test case

Mark Weiser spent the best part of his life working on Ubiquitous computing. He has another noted work as well in which he indicates all social and knowledge work is all about reducing the problem to reach an agreement , where he explains reality distortion with the classic archetype the Dilbert. And there are measures that you can use, to reduce Reality Distortion and for those academically oriented there are complex equation to represent them, but I like the cartoons better.

 The real issue I think is, can we design boundary objects and reduce the reality distortion differences over a period of time?

Standard
cognoise

Fixed Price versus Time and Material billing

You know in Bangalore you can buy a Pre Paid auto ride from station to anywhere in the city.

You just buy a token for 1 INR to ride and pay the amount at the end of journey.

This is Fixed Price, you do not care which route the driver takes and do not try to influence him in anyway. If you are lucky you get a driver who knows the route and you reach your destination safe.

In some rides something interesting happens during the journey, you will get to know a totally different alternate route to the destination that you have never tried before or aware, it also happens to be the shortest. The shorter the route the better it is for the driver in terms of ROI.

Even if the driver is no genius or mostly does not know how to collaborate with you or the city, you won’t make a loss, till he gets to your destination, as all effort and expenses are the drivers’. But you will still lose time.

But the journey back from anywhere in the city to station is never pre-paid and it is a journey in which the meter is running, and you as a rider is managing which way the auto is going and trying to optimize your journey for less time (lesser traffic signals) and fare (shortest route).

Remember you don’t have control on the meter, you are less likely to get a heart attack by just believing it is a honest meter, but you have to pay what it shows at the end of the journey. The return journey to the station is TnM model (Time and Material).

You can think of yourself as a success when you can beat the pre-paid amount on the return journey. But remember there is always a better route home with another genius auto driver.

 
Image Credit Autorickshaw 2 by Knile

Standard