Archive for January 2008
The discarded peel of the fruit of musa acuminata has been used by many cartoonists and animators to extract a few laughs while making a point about unexpected and unforeseen dangers. Project management jargon refers to such hazards as unknown unknowns, a term that got some media attention a few years ago through the the near-poetic utterances of an erstwhile Secretary of Defense. The perilous peel provides an excellent metaphor for unknown risks that can cause project managers to slip up.
What I like about the banana skin metaphor is that it suggests ways in which project managers can prepare for unforeseen events that could derail their projects. These risk mitigation strategies, as they are referred to in the Advanced Project Pedant’s Dictionary, are well known. However, the analogy affords an opportunity to view these from a different perspective. So here they are – simple strategies for avoiding project banana skins:
Watch where you’re going…: This has got to be at the top of the list. If you don’t look ahead, you’re definitely going to make involuntary metatarsal contact with any peels that are in your path. Yes, I know it’s impossible to foretell the future, but it is often possible to foresee potential problems by staying in touch with what’s going on on your project. This includes being aware of status of deliverables, potential problems (as seen by indivdual team members) etc. etc.
…but look around too: Perhaps you see no peels in your path at present. However, that doesn’t mean one won’t appear later – people eat bananas all the time, and not always within range of a garbage bin. Often project managers focus on their work to the exclusion of all else happening in the organisation. Always remember that there’s a larger world out there, one which can affect your project in unexpected ways. An example: a senior developer defects to the competition unexpectedly. It is therefore important to stay informed of developments that could have consequences for your project. A good way to do this is by developing informal channels of communication within the organisation.
Pad your posterior: Despite your best efforts, you will at some point go heels-over-head on account of a fruit peel. Padding your rear can help reduce some of the nastier consequences of the encounter. Such protection against unforeseen occurrences is sometimes referred to as management reserve in project (and risk) management jargon. This usually amounts to a monetary allowance for the adverse fallout – for example, funding for a contractor to replace the disloyal developer.
An authoritative source claims that present-day pedestrians possess immensely improved peel perception. It now remains for project managers to follow suit. The foregoing suggestions may help.
Many businesses implement their IT projects with the help of external parties such as consulting or software firms. In these projects, the eventual outcome – success or failure – depends critically on the relationship between the business (the customer) and the external party (the vendor). At one extreme, the relationship could be almost adversarial – which happens quite often. At the other, it could be collaborative – which happens not often enough. A recent paper entitled: A negotiation approach to project sales and implementation, published in the Project Management Journal provides a framework to support and enhance the latter approach. In this post I review the paper from a practical perspective , asking the question, “Does the paper offer any insights or ideas of immediate value to a practising project manager?”.
The short answer is a qualified, “Yes”. Read on for more.
The authors contend that project related negotiations typically suffer from the following shortcomings:
Negotiations between the customer and vendor, which take place at various stages of the project, are typically “local” – i.e. they’re made in isolation, without much regard to possible consequences on subsequent phases of the project.
The parties approach each of these local negotiations with only their own interests in mind, leading to a win-lose or distributive approach wherein one party gains at the expense of the other.
People involved in the discussions are typically not trained negotiators. Consequently they approach the negotiations in an unsystematic manner.
To overcome these shortcomings the authors suggest the following:
A project be viewed as a continuous process of joint decision-making that lasts through the project. The operative words are the italicised ones – emphasising that optimal outcomes can only be achieved through:
a project-wide view as opposed to a local one and,
a win-win or integrative approach to negotiations.
The discipline of negotiation analysis be used to analyse and prepare for negotiations.
Negotiation analysis combines techniques from game theory, decision analysis and behavioural decision analysis . Additionally, negotiation analysis also includes subjective information, such as perceptions etc., that do not have analytical backing. It also acknowledges that negotiations often end up leaving both parties with sub-optimal (or inefficient) outcomes. This essentially because the negotiating parties do not exchange information that would enable them to reach efficient agreements – i.e. the parties do not collaborate. The goal of negotiation analysis is to improve collaborative (or joint) decision making to the benefit of all parties involved.
A large part of the paper is devoted to discussing the authors’ conceptual framework for project negotiations. I suspect many practising project managers will find the treatment a tad theoretical and somewhat idealised. That said, the authors do make practical suggestions on how a qualitative application of negotiation analysis can assist in managing project negotiations. I found the paper interesting, and recommend it to practitioners, if only for the suggestions it offers in improving ad-hoc approaches to project negotiations.
Kujala, J., Murtoaro, J. and Artto, K., A Negotiation Approach to Project Sales and Implementation, Project Management Journal, 38 (4), 33-44(2007).
The stereotypical corporate IT employee has a reputation for uncooperative behaviour. The most common manifestation of this is his tendency to turn down requests from the business with a resounding “NO!”1. Unfortunately, this trait doesn’t endear him to the folks upstairs2, and a few such refusals soon translate into a company-wide negative perception of the entire IT crew.
Now, as some say, perception is reality3. So, the employee, despite his ever-mounting frustration with (what he perceives to be) ever-increasing workloads, needs to handle his customers with a little tact. He needs to learn how to say “no…” in a softer, exclamation-free, corporately-acceptable manner.
How so? Well, by using positive negatives – i.e. by putting a positive spin on the refusal. There are two ways to do this. By presenting:
Alternatives: This essentially amounts to saying, “No, but how about <insert alternative here> instead,” or
Compromises: This is a qualified “yes”. For example, “Yes, but not before next week.”
In either case, our unnamed protagonist would want to ensure that he can actually deliver on the alternative or compromise.
Obviously, the technique of positive negatives works in any area (consultants use it all the time), and the naysaying, nameless IT hack is merely a straw man to illustrate my point. So – and particularly if you’re a present or erstwhile colleague of mine – be assured that he’s a figment of my imagination.
1 Some members of this mob are known to issue relatively verbose refusals such as, “No, that’s impossible because <insert random reason here >”.
2 We are talking stereotypes so the person’s a male, he’s overworked, and the IT department is in the basement – safely quarantined from the rest of the business.
3 See this post and the accompanying discussion for an interesting, if somewhat philosophical, counter-view on perception and reality.
In recent years there’s been a proliferation of _ Driven Development methodologies, where the underscore can be substituted by just about any letter of the alphabet. Some examples include: Behaviour Driven Development (BDD), Feature Driven Development (FDD) and Test Driven Development (TDD). What is perhaps not as well known, is that the world of in-house application development has its own A to Z of _DD methodologies. In this post I offer short notes on those that have gained popularity (notoreity?) in Corporate IT shops.
For convenience (mainly mine!) I go through half the alphabet here, with the strictly non-binding promise to cover the remainder in a future post.
Off we go then:
Arbitrarily Driven Development: ADD, which has many adherents in the corporate world, is characterised by a complete lack of planning or process. Also see item 3 below. This is sometimes referred to as Cowboy Coding.
Bulldust Driven Development: BDD is employed when end users don’t have a clue as to what they want. An (often unstated) implication is that developers don’t have a clue either.
Confusion Driven Development: See ADD above.
Desperation Driven Development: DDD, which is characterised by frantic, undirected activity, is often resorted to when a project runs short of time, money or any other resources.
Everyone Driven Development: This is used when every user (and potential user) wants to have a say in defining application requirements.
Finance Driven Development: Useful when saving money is the major consideration. The methodology is characterised by ruthless cutting of corners rather than code.
Google Driven Development: Development by way of this methodology is popular when the project team doesn’t have a firm grasp of the technology involved. Consequently the team spends many hours filling in the gaps via the well-known search engine.
Helicopter Driven Development: This occurs when the effort is lead (piloted?) by someone with a birds-eye of the project. Difficult and nitpicky details tend to be glossed over, much to the distress of developers.
Idiot Driven Development: This is where the project decision-maker has strong opinions coupled with little sense. See this post on Scott Berkun’s blog for more. Note that he uses a stronger, perhaps more appropriate, word to describe the decision-maker. This methodology is also known as…
Jackass Driven Development: See Idiot Driven Development above.
Killjoy Driven Development: Is when the project lead is a confirmed pessimist who keeps going on about how the team’s never going to make the deadline.
Luck Driven Development: This happens when the team hasn’t a prayer of making the deadline. They press on regardless, relying on Lady Luck to do the right thing by them.
Myopia Driven Development: This is when the project lead and the project team have no visibility of the project beyond a few days. Some dignify this mode of working by claiming they’re using Rolling Wave Planning. Don’t be fooled, though; they really don’t know where they’re headed.
Admittedly, these methodologies aren’t as well known as others that have gained acceptance through their utility or agility. This post is my small contribution in increasing general awareness of these (strictly non-agile) development methodologies.
Stay tuned for N to Z.
Ah, motivation! All project managers want to find that magic button that will, when punched, fire up their teams to ever-higher levels of achievement. I’m no different. So when a paper entitled, Motivation: How to Increase Project Team Performance, appeared in a recent issue of the Project Management Journal, I was motivated enough to give it a read. Unfortunately, I was a little disappointed on reading it. Although well written, and perhaps even useful to practising project managers, the paper does not belong in a professional, peer-reviewed academic/research journal. Read on for my reasons why.
To begin with, a paper published in a peer-reviewed academic/research journal ought to contain one or more of the following:
A new or different perspective on existing knowledge.
A comprehensive critical review of an existing area of knowledge.
This paper contains none of the above – a claim which I substantiate below. Ergo, it doesn’t belong in an academic or research journal.
And so, on to the content.
The paper begins with a review of existing theories of motivation. The usual suspects are all present and accounted for: McGregor’s Theory X and Theory Y; Herzberg’s Two Factor Theory; McClelland’s Theory of Needs and motivation based on individual Myers-Briggs personality types. The applicability of each of the above – which the author lists under “roles and responsibilities”, “advantages” and “disadvantages” – are well known, and the paper adds nothing new.
The next section discusses the impact and resolution (or correction) of so-called “motivational mistakes” that are outlined in the book Essential People Skills For Project Managers by Flannes and Levin (see pages 80-81 of the book). These “mistakes” – which are essentially ineffective techniques often used to motivate people – include approaches such as: “whatever motivates me will motivate others” or “they are are professionals and don’t need motivating” etc. (see the paper for a complete list). These “mistakes” are well known, as is their impact and resolution (see the book listed above, for example)
The author then delves into the use P-CMM framework in the context of project teams. Regardless of the utility of the framework in improving processes for managing and developing workforces (and opinions on this vary), the paper does not state anything new on the topic. Advice such as laying out well defined expectations, having well defined project processes, involving the project team in planning etc. etc. are offered. However, these have long been a part of project management lore.
In the penultimate section, the author offers some “directives” (which I prefer to interpret as advice) to assist in the development of a “team culture”. Most of the advice offered is, again, well known. The fourth item in the list, for example, states, “Reward the team and the team members.” So tell us something we don’t know…
The paper concludes with the observation that, “...Taking the time to to work with each team member to understand personal work drivers will allow the project manager to uncover basic human needs and individual motivators.” No contesting this point, for sure. But again, what’s new?
Having reviewed the paper, I should reiterate that it is well written and worth a read for practising project managers – if only as a reminder of what they already know. My main quibble, as you’ve undoubtedly gathered, is that the material presented isn’t new or comprehensive, and as such does not fulfil the criteria for a paper in an academic or research journal.
Peterson T. M., Motivation: How to Increase Project Team Performance, Project Management Journal, 38 (4), 60-69 (2007).
The trade media plays a major role in
indoctrinating informing corporate IT decision-makers about new idealogies developments in enterprise technologies. In fact, many IT folks first hear of a new technology (or architecture, or whatever) through journals such as Computerworld, and before we know it a shiny new bandwagon starts to roll. It was therefore refreshing to see this article in CIO Magazine, reminding corporate IT punters to be wary of media (and vendor) generated hyperbole regarding emerging trends in technology. In this post I offer my approach to dealing with this issue.
The questions one should ask when evaluating new technologies are age-old ones: what, why and how. I elaborate below.
What is it about? The first step is to understand what the technology is about. You don’t need to figure out all the nuts and bolts at this point. What’s needed is a high level understanding, untainted by media hype. You may need to consult your in-house experts for this, but beware of distracting them from their ongoing work. Armed with an understanding of the technology, you can move on to the next question which is…
Why do you want to use it? Or stated another way, would your business benefit by using it? There could be several good reasons for implementing a new technology. On the other hand, there will be several more bad ones. You need to ensure that your reasons are the former, not the latter. In this context, it helps to focus on business benefits rather than technology. You’re unlikely to get the go-ahead if there is no demonstrable business rationale for implementing the new technology. If you find there’s none – stop! Else, proceed to the next question which is…
How do you implement it? Before you present your recommendations to the business for approval, think about how you will proceed if you did get the go-ahead. Some senior managers may want to see this information before they give their approval, so it is important you have it on hand. Things to consider include: implementation steps, personnel involved (internal and external), rough estimates on budgets, schedules etc.
Now you have enough to build a business case detailing the benefits of using the technology, and how you intend to implement it. Your business case should enable senior management to make a well-informed decision on whether to go-ahead with the new technology or not. If you do get the green light, the work you’ve put in evaluating the technology will also help in developing a project plan.
Trade journals will continue to promote technologies, often uncritically. The responsibility for separating the grain from the chaff lies with those who work at the interface of business and technology. The winnowing begins with the simple questions: what, why and how.
Most textbook definitions of the art of management (or science, depending on one’s leanings) aren’t particularly edifying. They all somehow seem to miss the essence of what it means to be a manager. Judge for yourself – here are some definitions of management gleaned from online resources:
Directing and controlling a group of one or more people or entities for the purpose of coordinating and harmonizing them towards accomplishing a goal. (Source: Wikipedia)
The process of getting work done through people (Source: UNR College of Business Administration, attributed to the American Management Association).
Additionally, this article provides an annotated compilation of definitions.
My problem with each of the above definitions – including those in the article – is that they emphasise a superior-subordinate relationship between the manager and the managed. Now, the good managers (that I know) go to great lengths to downplay the “I’m the boss” aspect of the relationship. Yet, the definitions – through their use of words like direct, control, supervise, manipulate, get done etc. – continue to propagate a distorted notion of what it really means to be a manager.
To date, the best definition I’ve seen is tucked away in half a line on page 19 of Scott Berkun’s book, The Art of Project Management. Here it is; a simple and succinct definition that captures the essence of what it means to be a manager:
Managers (are hired to) amplify the value of everyone around them. (Source: Scott Berkun, The Art of Project Managment, O’Reilly Media Inc., Sebastopol, 2005 – Page 19)
“That’s it!”, I thought, when I first read it.
What I like about this definition is that it downplays the superior-subordinate aspect of management, which is not that important anyway. Instead it highlights the fact that everyone has something to offer (special skills, talents, whatever), and that a manager’s job is simply to amplify that “something” to best effect. As an aside I should add that, in my opinion, the tired debates on management versus leadership are misplaced, as (good) management encompasses many elements of leadership as well.
I’m interested in your opinion. What do you think – does Scott Berkun’s definition capture the essence of what it means to be a manager? Let me know through your comments.