Eight to Late

Sensemaking and Analytics for Organizations

Archive for April 2008

Blinded by the light – when project management methodology matters more than project success

with 8 comments

Many organisations believe (hope?) that strict adherence to a project management methodology  guarantees project success. These unfortunates have been blinded by the dazzling (but false) promise of whatever methodology they choose to follow, and their projects suffer for it. My feelings on this are strong, but with good reason. I’ve seen too many projects go awry because of blind devotion to methodology.   

The first step to fixing any problem is to recognise that it exists. So how can you tell if methodology has taken over your organisation? Well, here are a few warning signs:

  1. The focus is on following The Book rather than getting the job done: A classic sign of methodology madness is when things are done a certain way just because the process mandates it. This is sometimes seen in organisations with a strong project management office (PMO). To keep the powers that be happy,  project managers often end up following the letter of the process but not the spirit, using other (informal) means to get the job done. 
  2. There are templates for everything: The Book has a long appendix with templates for every conceivable action. You want to sneeze?  Sorry, it has to be approved first. Please fill in form SN123, and we’ll pass on your request to the appropriate committee for review. Expect to hear from us in a week or so.
  3. Signatures / Approvals for everything: This is a particularly pathological variant of the well known, “Responsibility without authority” challenge that project managers face. Here, in addition to the lack of authority, you also can’t use informal channels to get things done because you need to have a paper trail to prove authorisation.
  4. Every action is over-deliberated: Is every project action re-visited and re-analysed ad-nauseum? If so, your project’s suffering from process sclerosis (a close cousin of analysis paralysis), wherein mindless application of process slows progress to a crawl.
  5. Everything is cast in stone: You want to do some things in a different way? Sorry, that’s not possible. The methodology has a prescription for every conceivable project action. No exceptions. 
  6. Project management is a bureaucratic exercise: Project managers in methodology heavy organisations often end up becoming bureaucrats who spend  most of their time fulfilling the requirements of the methodology. This leaves them with little time to actually manage their projects. Methodology has become an end in itself. Good luck getting anything done – you’ll need it. 

Lest I leave you with the impression that I’m completely anti-methodology, let me assure you that I’m not. I’m a great fan of appropriate, well-considered use of project management processes. What do I mean by that? Well, many years ago a project management guru told me that every process employed in a project should be tailored to to that particular project’s needs and circumstances. Note his emphasis on the singular; each project is unique (by definition!) and must be treated so. Project management processes used in a project should be fit for purpose.

So I end with this thought: don’t let your organisation be blinded by methodology. Instead, insist that project management tools and techniques be used appropriately, in a manner that illuminates the way ahead on particular projects.

Written by K

April 28, 2008 at 6:19 pm

Managers aren’t good at listening

leave a comment »

 Are managers good listeners? This is the question Patrick Barwise and Sean Meehan address in a note published in the April 2008 issue of the Harvard Business Review. The research conducted by Barwise and Meehan indicates that managers tend to overrate themselves on their own openness to frank communication; the  gap in self-perception being greatest when the views expressed are contrary those held by the manager.  This conclusion is based on  360 degree surveys of more than 4000 US managers across a range of industries and functions.  

The authors believe there are two factors at work here. Bosses tend to:

  • Overestimate their openness to contrary views, as indicated by the wide differences between self evaluations and those of colleagues. 
  • Underestimate the extent to which the manager-managed relationship hinders their subordinates from communicating openly. That is, subordinates fear reprisals of some kind if they are the bearers of bad news or contrary views.  The authors reckon  this happens because bosses often unknowingly  send out subtle signals discouraging their subordinates from speaking openly.

To get around this,  they suggest that:

  • Managers should assume they are less open to frank discussion than they think they are.
  • Organisations should use 360 degree surveys specifically targeted to uncovering communication issues. They reckon that bad managers, when confronted with real data may be more open to changing their ways (Good luck with that, I say).

There’s no doubt (to me, at any rate)  that Barwise and Meehan are right in their observations about managerial openness to frank communication . Most of us – managers or not – don’t like to be contradicted, and that’s no surprise.  

On the other hand, I’m not so sure about their recommended solution. In my opinion fixes at the individual level, such as they suggest,  will not work.  I believe open communication needs to be fostered at the organisational level for it to permeate right through the corporate hierarchy. Put differently, it is an issue of organisational culture rather than management.  Some workplaces have a culture conducive to open communication; others don’t. Those that don’t would not be able to fix the problem by confronting managers with the results of 360 degree surveys (or any other data for that matter). Given the anti-communication culture of the organisation, the said managers would simply deny there’s a problem and worse,  may even confront those who they think are responsible for the negative feedback. In fact,  because of the latter, such surveys may not even indicate there’s a problem as subordinates would not risk saying what they really think.

I’m interested in knowing what you think about this. Let me know via your comments.

Written by K

April 24, 2008 at 6:02 am

Are project management skills generic?

with 4 comments

Jack’s a good friend of mine. A few days ago we were talking about this and that, when the conversation veered to project management:

“By the way, ” he said, “we’re looking for a new project manager for the CRM project I told you about last week. Would you know anyone who might be interested?”

“What kind of person are you looking for? Do you want someone with significant PM experience or do you want a CRM expert?” I replied. I have this annoying habit of answering a question with several questions.

We went back and forth a few times and ended up drafting out an advertisement for the position.

Let me ask you now: what do you think is more important for a project manager – domain knowledge (i.e. expertise in a specific subject area ) or project management skills and experience? 

My opinion? Although some domain knowledge is helpful and perhaps even important, many key attributes of a good project manager are skills which are applicable across a wide range of industries. I’ve thought so for a while, and this paper which I reviewed in an earlier post, appears to strengthen my position. After all, if practices are generic, skills should be too.

I set about performing an (admittedly unscientific) survey to see if this is indeed so. Here’s what I did: I looked at several online job postings for IT project managers. On sampling ten of these at random from a well-known local job site,  I found that many advertisements listed similar skill and experience requirements. Below I list the skills and attributes that appeared most frequently in the advertisements surveyed (frequency of appearance in brackets). 

  1. Communication skills (8) 
  2. Problem solving / analytical ability (6)
  3. Vendor / stakeholder management (6)
  4. Ability to work under pressure (6)
  5. Negotiation skills (5) 
  6. Understanding of project lifecycle /  methodology (5)

Note that I’ve incorporated similar attributes into a single point – e.g. Exceptional written and oral presentation skills and Good verbal and written communication skills have been combined under Communication Skills.

It is interesting that domain knowledge  does not appear in the list. This attribute came in just under the cutoff mark, with four ads specifying  it as a requirement. What’s even more interesting is the skills and attributes listed above are generic – i.e. they are applicable across projects in any domain.  So, my survey, for what it’s worth, indicates that the answer to the question posed in the title is, “Yes, the most important project management skills, as determined by what employers look for, are indeed generic.” 

Written by K

April 19, 2008 at 11:52 pm

Posted in Project Management

A project procrastinator’s tale in five limericks

with one comment

Gathered there was the whole team,
at the late project’s autopsy.
They laid no blame,
but it was me – oh shame!
It was all my fault as you’ll see.

It started out feeling great
I’d padded every estimate
with lot of air,
much time to spare.
So why did it turn out so late?

The reality, if truth be told
is that I just cannot behold
the sight of work.
I simply shirk.
Even thinking of it turns me cold.

So, although I say I tried,
I was the reason the project died.
The work on my plate
was always in late,
with excuses that couldn’t be denied.

Procrastination’s the thief of time.
It only makes one fall behind.
So, try if you can
to stick to the plan.
Don’t wait for intervention divine.

——

Other pieces in my five limericks series are:

A project management tragedy in five limericks

A corporate IT tragedy in five limericks

Reply to a corporate IT tragedy in five limericks

Written by K

April 17, 2008 at 10:09 pm

The effect of organizational culture on knowledge transfer in projectized organisations

with 9 comments

The knowledge gained during the implementation of a project is often lost after the project is completed. This loss carries a huge cost as future project teams have to rediscover lost knowledge, or reinvent the proverbial wheel.  Although learnings are often (or should I say “sometimes”?)  documented in project post-mortems or lessons learnt documents, these are rarely, if ever, read by project teams down the line.  Management and transfer of knowledge involves complex processes which, in turn, depend on several factors that vary from organisation to organisation. One such factor is organisational culture.  A recent paper entitled, Knowledge Transfer in Project Based Organizations: An Organization Culture Perspective, published in the Project Management Journal investigates obstacles to knowledge transfer in project-based organisations, with particular emphasis on the role of organisational culture. I summarise and review the paper below.

The authors begin by a brief overview of what is meant by knowledge and how it is created. They distinguish between data (unprocessed facts), information (meaningful aggregations of data) and knowledge (information that is processed and filtered on the basis of an individual’s perception, skills and experience). Knowledge involves  assimilation by the human mind whereas data and information do not. The authors also draw a distinction between explicit and tacit knowledge, i.e. that which is documented and that which is undocumented, often existing only in people’s minds.  According to the SECI model proposed by Nonaka and Takeuchi,  new knowledge is created by an interaction between tacit and explicit knowledge through the processes of Socialisation, Externalisation, Combination and Internalisation. Other researchers claim that explicit knowledge is an extension of tacit knowledge to a new level, whereby it is “consciously known” and hence can be transferred to others.

The authors then move on to discussing how knowledge is transferred. Their discussion is based mainly on a paper by Nissen and Snider (see abstract), which describes three views of project-related knowledge transfer:

  1. As solution – wherein knowledge is transferred on the job – i.e. when working on projects. In this perspective, managers facilitate knowledge flow by ensuring selection of appropriate technologies  and motivating individuals to use them.
  2. As experience – wherein knowledge is transferred by capturing experiences (by documentation, for example) for future reference. Here the emphasis is on flow of knowledge across time. An example of this is when knowledge is transferred from one project team to another.
  3. As socially created -wherein knowledge is created (not transferred!) through interpersonal interactions (discussions, arguments and other informal communications). The challenges associated with this form of knowledge transfer are primarily in fostering an organisational culture that encourages informal communication. Although this may be considered outside the ambit of a project manager’s responsibilities, a project manager can  help by fostering a communication-friendly culture within the project team.

The authors then point out that project management has grown beyond its traditional role of planning, controlling and monitoring projects to a more strategic role of resource optimisations and inter-departmental collaboration – which ultimately ends up providing better customer service.  I’m not sure why they throw this point in, as it seems like a side issue to the main focus of the paper. Perhaps it is to emphasise that effective knowledge transfer processes become more critical as project management takes on a more strategic role in organisations.

Project teams are often required to find and assimilate knowledge that exists in organisational memory. The authors suggest that this task is easier in functional organisations than in projectised ones, because in the former, knowledge is organised and stored by department (and hence, presumably, easy to find).  I beg to differ: In my experience the task can be just as hard in functionally structured organisations.  This is true for most of the other knowledge transfer obstacles they mention, such as: volume of documentation, no time to document etc. etc. My point: knowledge management problems listed by the authors aren’t unique to project-based organisations.

Next the paper looks at the classification of project-related knowledge. Here the authors follow the work of Conroy and Soltan, who suggested that all project-related knowledge falls into one of the following: an organisation knowledge base, a project management knowledge base and a project-specific knowledge base; each being developed (or augmented) during the implementation of projects. Since projects are the only means via which knowledge bases are enhanced, it is important that project learnings are captured effectively.

Having discussed the need to capture project knowledge and the importance of project-specific knowledge, the authors move on to a discussion of obstacles to knowledge transfer in projectised organisations. They identify the following road blocks to knowledge transfer:

  1. Project constraints leave little time and resources for effective documentation of knowledge.
  2. The existence of significant social and cultural barriers to knowledge transfer. These are things such as: lack of openness, no tolerance of failure, blame culture etc.
  3. Lack of motivation (or incentives) to undertake project reviews. This is the well known wiifm factor.
  4. Lack of leadership that accords enough importance to developing the organisation’s knowledge base.

The authors contend that these issues boil down to inadequacies in organisational culture. Stated another way: the transfer of intrinsic knowledge (which exists in people’s minds) can occur only in an organisational culture that supports it.  This definitely rings true, and I don’t think any project manager would argue with it. I would add that the aforementioned obstacles are alive and well in all organisations – not just project-based ones.

Having established that a supportive organisational culture is critical to knowledge transfer, the authors move on to  discussing the cultural variables that promote knowledge transfer. In particular, they discuss models by West and Schneider.

West proposes the following two dimensions of organisational culture:

  1. Flexibility versus control: this measures the degree of organisational control. Specifically, flexible organisations tend to have flat hierarchies, decentralised decision making as opposed to controlled organisations which have rigid (and often deep) hierarchies and centralised decision making.
  2. Internal versus external orientation: this measures the degree to which the organisation is affected by its cultural environment. Although organisations are situated in a greater cultural context, the extent to which they are affected by it can vary.

As compared to control-based organisations, flexible organisations are characterised by flat hierarchies and decentralised decision making.  The authors mention that rigid structures and hierarchies promote efficiency, though often at the expense of innovation and collaboration.   In my experience in control-based organisations, the emphasis on efficiency and control often leads to an overemphasis on process, which is ultimately what reduces any possibility  of collaboration and innovation.

In contrast to West, Schneider proposes the following dimensions of organisational culture:

  1. Possibility versus actuality: this relates to what the organisation focuses on – potentialities or facts.
  2. Personal versus impersonal: this relates to how decisions are made in the organisation – process driven (i.e. by logic) or based on feelings, beliefs, ideals (i.e. all those “warm and fuzzy” notions).

These axes divide the universe of organisations into  four core cultures:

  1.  Control: a process driven culture which values certainty and predictability above all.
  2.  Competence: a culture that values excellence (in services or products). These organisations aim to have unique or best of breed products and services.
  3.  Collaboration: this culture emphasises close connections with customers and collaborative working towards developing products or solutions. This is essentially the  opposite of a competence culture.
  4. Cultivation: this  culture emphasises openness, autonomy, ideals and ideas. These organisations tend to be innovative. This is essentially the opposite of a control culture.

It is intuitively clear that the above dimensions of organisational culture will have varying effects on the efficacy of knowledge transfer. The authors, however, do not delve into these. So their coverage of models of organisational culture, as interesting as it is,  seemed a little pointless in the context of the paper.

Next the authors point out that since project teams consist of individuals drawn from various professions, one needs to consider the effect of professional culture as well. This is an interesting point, which complicates matters because different professional  cultures approach communication in different ways – the example of IT and business cultures being a particularly stark case in point.

Finally, the authors end with a very general discussion of how knowledge transfer can be promoted in projectised organisations. They suggest that managers should:

  1. Recognise different levels at which knowledge is generated – i.e. individual, group and organisational.
  2. Appreciate the role of organisational culture in promoting or hindering knowledge transfer between these levels.  They suggest the primary barriers to knowledge transfer are cultural rather than technical (See this article by Suzanne Koudsi, for an interesting case study).
  3. Understand the role that management plays  in fostering a culture that facilitates knowledge transfer. This is particularly true for project managers who have to deal with many different cultures (organisational, departmental and project team) simultaneously. Awareness of cultural differences can help managers find the cause of obstacles to knowledge transfer.
  4. Appreciate the challenges involved in transforming organisational culture.
  5. And finally, since projects are the coalface at which knowledge is generated, practitioners must understand the issues that need to be addressed to facilitate gathering and preserving of relevant knowledge generated during project implementation. Some examples of these include communication modes between team members, what worked well in the project, what can be improved and how it might be improved,  etc.

Having covered a lot of ground (somewhat skimpily, in my opinion), the authors conclude the paper with three very general statements:

  1. Effective knowledge transfer can occur only if the organisational culture is open to accepting new knowledge transfer activities. Managers must therefore prepare the culture to accept, adopt and implement these activities.
  2. In addition to knowledge transfer, knowledge management is also about fostering an organisational culture that encourages the creation, sharing and utilisation of knowledge.
  3. Project managers have to merge myriad organisational, departmental and professional cultures into an effective project culture that promotes knowledge management.

Although project managers may appreciate these points (and I suspect many do), there’s little they can do about changing an organisation’s cultural mindset. All they can do is ensure that they establish a culture that fosters knowledge transfer within their  own projects (point 3 above). Some ways to do this include: encourage collaboration between team members, establish a no-blame environment etc.

In conclusion, the paper was reasonably interesting but somewhat hard to read because it was thin on detail, and occasionally veered from topic to topic without proper transition or introduction. I suspect this is because the authors assumed their readership would consist entirely of academics with a strong grounding in project management theory. This is a pity because the paper, if better written, could have been of considerable interest to practising project managers. So I end this review with a plea to  journal paper authors: when writing your paper, please remember that project management isn’t just an academic discipline.

References:

Ajmal, M. M. and Koskinen, K.U., Knowledge Transfer in Project-Based Organizations: An Organizational Culture PerspectiveProject Management Journal, 39 (1), 7-15. (2008).

Written by K

April 12, 2008 at 5:19 pm

Great expectations and how to manage them

with one comment

Many project management books contain a section or two on managing stakeholder expectations. The emphasis in most of these tomes tends to be on the bureaucratic aspects of the process – developing stakeholder management plans or getting the project scope statement signed off, for example. Although documents and signatures may be useful in proving that you’ve performed your duties with due diligence  (aka CYA),  they don’t guarantee stakeholder satisfaction. Despite reams of documentation, a good number of projects are deemed failures because of a mismatch between stakeholder expectations and completed deliverables.  I’d go so far as to say that chronic project failure is one of the main reasons why many corporate IT departments get a bad rap.

The root of the problem, in my opinion, is that documented requirements very often do not reflect what a client really wants. It is impossible to get a comprehensive view of client requirements in a limited number of analysis sessions. This difficulty is particularly acute when one tries to document all requirements in one go, as is the case when a waterfall development methodology (also known as Big Design Up Front or BDUF)  is used. It is well known that Iterative / Incremental methodologies are better because they ensure that requirements are reviewed and revised several times in the development cycle. Incidentally,  this article by Joe Marasco  has an excellent, visual explanation of why iterative development is superior to BDUF.  Despite this being common knowledge, many corporate IT departments remain stuck under the waterfall. Why this is so is a topic for another post – I’ll just take it as a given here. However, consequent stakeholder dissatisfaction is one of the major reasons why these departments have low credibility within the organisations they serve.

So what can be done about this?

The two-word answer: better communication.

The one-sentence answer: adapt flexible stakeholder management practices from the Iterative/Incremental world and integrate them into your BDUF approach.

The longer answer:

Iterative/Incremental approaches mandate regular meetings between stakeholders and project team members. Consequently these methodologies have stakeholder management built in, as opposed to BDUF approaches which don’t require regular interactions.  So when using BDUF methodologies one has to work doubly hard at communicating with stakeholders. When doing so, it is a good idea to adapt practices from Iterative/Incremental approaches and integrate them into your development methodology.  In particular, the following points are worth considering:

  • Frequent feedback: You don’t need to schedule formal meetings to give people status updates or feedback. Wander over to their office to have a chat and give them an update. If you make a habit of this, you may even find that formal meetings are required less often.
  • Frequent delivery (or demos): Although BDUF methods appear to preclude frequent delivery (as opposed to Iterative techniques, which mandate frequent releases), it is often possible to show users work in progress. Schedule informal demos of work in progress where a developer shows end users the current state of the product. By doing so, you may get feedback early enough to do something about it. It’s no good having users complain about the user interface at the final demo.
  • Flexible attitude: Yes, I know, your requirements are frozen (the users have signed off on them, after all). However, if you can accommodate changes, it is best that you do (via whatever change control process you have).  A blanket, “Next phase” response to all change requests will only annoy your clients. A flexible, can-do attitude will go a long way in getting users “on your side”. Once they see that you do your best to help them, they’ll (usually) reciprocate by not asking you for the moon. Further, on the rare occasions that you turn them down, they’ll (generally) understand that you’re doing so for good reasons. 
  • Present alternatives when saying no: This is important. If you do have to say, “No” to a user request, try to present a viable workaround or alternative. Often, a well thought out alternative may be more than enough to satisfy the user. Besides, it also gives the user a sense that you are working with them to solve their problems, and not off on your own trip building something that is divorced from their needs.

That’s it. I know, when you look at the list the points seem pretty obvious. However, they are hard to apply in practice – not just because of recalcitrant users, but also due to the numerous constraints on project teams operating in BDUF environments. In practice you’ll also find that these techniques work better on some projects than others – mainly because of differences in user attitudes.

Everyone has great (or should I say, inflated)  expectations from things to come. This invariably leads to disappointment in the end. A good part of managing users is to  make their expectations more realistic rather than lowering them. The best way to do this is by involving users as much as possible in the development process. This essentially is what Incremental/Iterative and Agile techniques advocate.  BDUF practitioners – which include many corporate IT development teams –  should take a leaf from their book.

Written by K

April 6, 2008 at 10:00 pm

Nursery rhymes for project managers

leave a comment »

Mother Goose for Project Managers – version 0.001:

Little Jack Horner
Little Jack Horner sat in the corner,
watching his budget run dry.
Said he to the sponsor, “The project’s a goner.
and I reckon, so am I.”

Hickory-dickory dock
Hickory-dickory dock
The PM’s in shock.
The project’s aground;
the clock’s run down.
Hickory-dickory dock

Jack be nimble
Jack be nimble,
Jack be quick.
Dodge responsibility,
for it tends to stick.

Hey diddle diddle
Hey diddle diddle, the schedule’s a fiddle.
The deadline’s near; it’s too soon.
The sponsor won’t smile when he sees what’s been done,
especially after being promised the moon.

Hush-a-bye PM
Hush-a-bye PM, on a timeline.
Better wake up now, things aren’t so fine.
The scope is a-creeping, are you on the ball?
No change management will be your downfall.

Schedule, Schedule
Schedule, schedule on the wall,
the PM’s going to take the fall.
’cause everyone can plainly see,
his timeline’s but a fantasy.

The PM can’t sleep
The PM can’t sleep, he’s counting sheep.
The project is what’s troubling him.
Changes galore. Tell you what’s more –
there’s no money left to fund ’em.

Blah blah PM
Blah blah PM, spouting bull.
I can’t take anymore, my plate’s full.
The workload here is driving me insane.
So I’m leaving for a gig with the mob down the lane.

Written by K

April 4, 2008 at 9:17 pm

%d bloggers like this: