Archive for the ‘Project Management’ Category
Zen and the art of project communication
Introduction
There is a curious disconnect between the theory and practice of project management: the former is epitomized by various BOKs and methodologies which lay out a rational framework for managing projects whereas the latter is the reality that project managers experience when they are immersed in the day-to-day activities associated with managing projects.
Although most organisations would claim that they have implemented a project management methodology of some sort, the actual day to day work of a project often proceeds with a logic of its own. Moreover, the requirements imposed by methodologies may even obstruct the progress of a project: it is not uncommon to hear of situations in which project managers and teams had to bypass their organisation’s processes in order to get things done.
The reason for this is not hard to find: projects – and indeed, organisations – are often faced with unexpected and unforeseen events. Typically, responses to such events have to be improvised, not planned. Although planners are expected to factor in uncertainty, what is not known cannot be foreseen. As we all know from experience, the future always manages to escape our carefully laid plans.
In this post I argue that the traditional (rational) mode of project communication – involving artifacts such as business cases, plans and status reports – is lacking when one has to deal with uncertainty. Instead of communication based on rationality (or arguments based on facts), an alternate mode that focuses on rhetoric (arguments based on values and emotions) may sometimes be more fruitful.
[Aside: in a strict sense of the term, rationality is a form of rhetoric, but in this article I’ll consider the latter term as applying to values and emotions.]
Shortcomings of “rational” project communication
Traditional project communication tends to be more about conveying information rather than encouraging debate. Specifically, project-related communications, be they verbal or written, emphasise facts and numbers rather than emotions and feelings. For example, a status report may convey the status of the project in terms of milestones achieved or figures such as percent complete. Moreover, even though a project manager may highlight qualitative information such as risks, he or she will do so in a way that assures the recipients that the assessments have been made in an objective manner. In short, project communications reflect the scientific-rational basis of project management itself.
In view of the above, it is no surprise that project communications tend to assume that the future can be predicted on the basis of clear cause-effect relationships. For example, project plans describe future deliverables that will be the outcome of certain planned actions. Indeed, that’s the whole rationale behind implementing project management processes – they are supposed to ensure that, if implemented right, the objectives will be achieved “on budget and on time” as envisaged.
That’s great in theory, but theory is good only for the classroom. As most of us know from experience, reality is messy: stuff happens; things turn unexpected in a thousand and one different ways. In short, our projects escape our plans.
How do people deal with this messiness? Closer home: what do you do when your project takes an unexpected turn south?
In such situations it is not unusual to feel that the seemingly rational edifice on which your project is based is not so sound after all. You may therefore be forced to examine the assumptions that you have taken for granted. Consequently, you may ask yourself questions such as:
Is my approach sound?
Am I doing the project right?
Or, even more basic: am I doing the right project?
It is difficult to answer questions with any certainty, particularly when the future events are yet to unfold. You need to make a decision, but to do so you need to get everyone on the same page. This is difficult to do because when facts are few, everyone seems to have a different opinion about what the “true” problem is and how it should be tackled. Some may even believe there is no problem at all.
A role for rhetoric
As we all know from experience, most people are attached to their opinions. It is going to take more than a logical argument to convince them to change their minds. Moreover, in situations of uncertainty and ambiguity, facts and numbers are scarce, and always prone to being contested by some recalcitrant stakeholders. So one has to work with opinions that are based on values and emotions rather than objective facts.
When one is attempting to convince people about something that depends on values rather than facts, the words and language constructs one uses are all important. That’s where rhetoric or the “art of debate” comes into its own. According to Wikipedia:
Rhetoric is the art of discourse, an art that aims to improve the facility of speakers or writers who attempt to inform, persuade, or motivate particular audiences in specific situations.
Of course, glib talkers (expert rhetoricians!) are often wrong, so it would be unwise accept rhetoric uncritically. One has to subject rhetorical arguments to scrutiny just as one would with any argument. The value of rhetoric, however, is that it gets people thinking along lines that they may not have considered otherwise.
In the present day, rhetoric has acquired a negative connotation because it is often used for dubious ends – for example, demagogues use it to whip up emotions and (some) politicians to vilify others. But conversely it might also motivate people to come up with creative ways out of difficult or even impossible situations. Some of the most inspiring and world-changing speeches in history are masterpieces of rhetoric (Martin Luther King’s, I have a dream being one that comes to mind)
…and so, to conclude
Most of us don’t want to change the world, we just want to get on with our jobs. My aim in this essay was to suggest the mode of communication that we have been programmed to use may not always be appropriate There is an alternative that may sometimes be better. Rhetoric isn’t just for lawyers and politicians; it has its place in the day to day work of managing projects. The “complete” project manager– if such a person exists –knows that there is no contradiction in this and, more important, tacitly recognizes when a particular mode of communication is appropriate.
…and in case you are wondering what on earth this has to do with Zen philosophy, the answer is: quite possibly, nothing at all.
One evening at the station – a project management fable
It had been an eventful day but Jack was still not done. He needed to update the schedule to reflect the bad news from the vendor and his development team. Then there was the status report. He was not looking forward to the meeting tomorrow. The sponsor would go ballistic when he heard about the delay. “I’d better do the status report before I go home,” he thought to himself. “Damned project is more trouble than it’s worth. I should never have volunteered for it …”
The phone rang flashing his home number. He ignored it recalling the morning’s conversation with his wife – she was expecting him to be home an hour ago. “S**t, talk about conflicting priorities,” he muttered to himself as he shut down his notebook and stuffed it in to his satchel, “I’ll have to do the status report at home.”
He dashed off to catch the 8:05 train; with luck he might be home in an hour.
But luck was not on his side that evening. He heard the rumble of the departing 8:05 as he bounded down the escalator to the platform. “Oh no, that’s another half hour gone, I should’ve stayed at the office and finished the status report,” he said to himself, shaking his head in annoyance.
He must have said that out loud because a gentle voice from behind him asked, “Tough day at the office, huh?”
He turned around, annoyed at the intrusion, “Excuse me…” he stopped himself mid-sentence when he saw the voice belonged to a wizened old man with twinkling eyes. Yoda was the word that came to mind. Jack continued in a friendlier tone: “Yeah, you could say it’s been a hard day.”
“What do you do for a living?” asked the old man.
Jack didn’t want the conversation but didn’t want to offend the old man either, “I manage projects,” he replied.
“Forgive my ignorance,” said the old man, “but what is a project and what does it mean to manage one?”
Jack rolled eyes (well, he didn’t really, but he felt like). “A project is an initiative to create something…like a new product or service within a specified time and budget. And managing it involves doing what’s necessary to make sure the product or service is created on time and within the specified budget.”
“So how do you do that?”
Jack was starting to get a little annoyed at the intrusion and he certainly did not want to get into all that PM 101 stuff, so he simply said, “There are a bunch of standard processes and techniques to run projects efficiently. They work well when done right.”
“How are they working for you right now?” asked the old man.
“Not so well. Why? Do you have some advice to offer?” he enquired pointedly.
“Why aren’t they working well?” persisted the old man, oblivious to Jack’s irritation.
“Oh, all kinds of reasons: politics people etc. – it’s complicated.”
“And you didn’t see these complications before they occurred,” stated the old man, more as a fact than question.
“Obviously I didn’t,” retorted Jack.
“Sorry, I didn’t mean to annoy with these questions but I can’t help but wonder if …”
Jack had had enough. “Please mind your own business,” he said shortly. “And if you’ll excuse me, I have a half hour before my train arrives and a stack of work to catch up with.” So saying, he strode to a nearby bench and sat down. Reaching into his bag, he pulled out his notebook and turned his attention to his unfinished status report.
The old man shrugged and wandered off towards the other end of the platform.
Jack, totally engrossed in his reports and plans, paid little attention to the announcements and the hubbub of the platform. He was used to working at the station, and knew that the rumble of his train would alert him that he needed to board.
And so he continued working.
About half an hour later, he noticed that the noise around him had subsided somewhat. That didn’t feel right. He surfaced from his reports and looked around. There were very few people about. “What’s going on?” he muttered to himself.
“Ah, I see you missed the announcements.” He hadn’t noticed the old man approach.
“What announcements?” asked Jack, a tad bewildered.
“Trains have been cancelled because of an accident further down the line,” replied the old man, ‘you’ll need to find some other way to get home…”
“S**t, that’s all I need, doesn’t anything work in this damned place.”
“There were at least a couple of announcements but it appears you missed them,” said the old man.
It was going to be an expensive cab ride home or another half hour wait for a bus followed by a 45 minute commute. Jack, sighing resignedly, stuffed his computer back into his bag and got up to go.
“It is good to pay attention to what is actually happening rather than what you think will happen,” said Yoda.
“Yeah, whatever,” said Jack as he turned and walked away.
“Perhaps there’s a lesson here for your work too: timetables and plans are not reality” said the old man.
Jack was taken aback. He stopped in his tracks, turned towards the old man and asked, “What do you mean?”
“I think I’ve said enough,” came the reply. “Make of it what you will.”
The old man shuffled away, leaving Jack to contemplate the long ride home.
On the politics of enterprise software implementation
Introduction
Project managers who have worked on enterprise system projects will know that the hardest problems to resolve are political rather than technical. Moreover, although such stories abound they remain largely untold, perhaps because those who have lived these stories are not free to speak about them. Even case studies in academic journals tend to gloss over political issues perhaps out fear of offending their hosts. Consequently there are not very many detailed case studies that focus on the politics of enterprise software customisation / implementation. In this post I summarise a paper by Christopher Bull entitled, Politics in Packaged Software Implementation, which describes a case study that highlights the complex and messy political issues that can arise in such projects.
Background
Given that IT tends to attract people with a analytical bent of mind, it is not surprising that those who plan enterprise scale system implementations focus on technical issues rather than politics. On the other hand, there is fairly rich research literature on the politics of system implementation.
In the paper, the author presents a short, selective review of the literature. The main point he makes is that the implementation of information systems is political because such systems are catalysts for organizational change. Some stakeholders may perceive benefits from certain changes whereas others will not. Given this, it is likely that the former group will be advocates for the system whereas the latter will not. Accordingly each side will present arguments that support their stance and these arguments will necessarily have a social/political dimension. That is, they are about more than just the technology.
A common way in which political behaviour manifests itself is as a resistance to the proposed changes. The author mentions that there are three theories of resistance, one each for origin / cause of resistance
- People-determined – in which resistance arises from a fear of change that is inherent in the human psyche.
- System-determined – wherein the change is resisted because the system is perceived as deficient or not useful.
- Interaction – where the system is seen as forcing a change in the culture and norms of the organisation. This is particularly the case for enterprise systems which tend to impose uniform work processes that are driven by the head office of an organisation, often to the detriment of efficiency in regional offices and subsidiaries.
Information systems academics tend to borrow heavily from other areas of the social sciences. It is therefore no surprise that there have been attempts to view the social aspects of information systems through the lens of Marxist theory. The parallels are obvious. Firstly, there are several different classes of people – management, developers and users – each with their own interests. Secondly, there are obvious inequalities in the distribution of influence and status between these groups. Case studies partially support Marxist theory – but I reckon this will not be a surprise to most readers.
The author points out that there are many different theories that can be used to make sense of social and political issues in information systems implementation. However, most of these tend to focus on one or another factor, overlooking others. In real life, political issues arise from diverse causes some of which may even counteract each other! The true value of focusing on the political aspects of system implementation is to gain an understanding of the causes of conflict and thereby develop techniques to alleviate them. It is here that case studies can be particularly useful because they allow researchers to study issues as they develop and thus developing an understanding of why they are happening and what could have been done to prevent them.
The case study
The study was carried out in a midsize, UK-based manufacturing company. The author noted the organisation had a hierarchical management structure with work organized by department. Interestingly, although management believed that communication between departments was good, other employees did not necessarily agree. Nevertheless, staff members were loyal and the company had a very low employee turnover rate.
The company was facing increasing pressure from competitors and had recently lost some key accounts. Management realised the organisation would need to become more proactive and responsive to customer needs, and this realization prompted the decision to implement a Customer Relationship Management (CRM) system.
The first decision that needed to be made was whether to build or buy – i.e whether the system should be built in-house or purchased. This decision has a political dimension as organisations often go down the “buy route” when they want to reduce the influence of their internal IT departments. However, building a CRM system is a huge undertaking and the IT department did not really want to be doing this. So the decision to buy rather than build proved to be popular with both IT and business staff.
Although the decision to buy the system was not contentious, the process of implementation turned out to be messier than either party had foreseen. Some of the problems mentioned by the author include:
- The project team (which was appointed by senior management) was widely thought to be unrepresentative. Groups that were not represented felt that their concerns would be ignored. Moreover, some felt genuinely threatened. For example, external sales staff (who were not included in the team or in project planning) felt that the system was intended to replace their roles.
- The steering committee was jointly headed by the IT and sales managers. This caused friction – the sales manager thought it undermined his authority whereas the IT manager viewed it as an unnecessary imposition on his time.
- Different departments had different views of what the system should do based on their respective departmental interests. Since it was difficult to achieve consensus, management engaged external consultants to assist the project team in requirements gathering and system sourcing/implementation.
- The consultants and IT had an adversarial relationship from the start. IT believed the consultants were biased towards a particular CRM product. There was also significant disagreement about priorities.
- Senior management appeared to trust the consultants more than the (internal) team members. This caused a degree of resentment and unease within the project team.
- Groups well represented on the steering committee (internal sales, in particular) were able to have say in how the system should work. Consequently, other groups felt that their concerns were not adequately addressed.
As a result of the above:
- Those who felt that their concerns were not addressed adequately indulged in delaying tactics.
- The project created a rift between employee groups had been homogenous in prior times. For example factions formed within the Sales Department, based on perceptions that certain groups (internal staff) would be better off after the system was implemented.
Moreover, effective use of the software entailed significant changes in existing work practices. Unsurprisingly, most of these changes were viewed negatively by employees. Quoting from the paper:
…new working practices were contentious because they were perceived to be unreasonable and unrealistic, particularly the scheduling and allocating of work for others. There were also complaints by certain sales staff that individuals who managed tasks at the beginning of the business chain would benefit considerably from those employed elsewhere because they were unaffected by internal organisational bottlenecks. Finally, the increasing number of surveillance features contained within the packaged system was resented by many sales support staff because of the pressures arising out of the increasing ability for managers to monitor and judge individual performance.
It is clear from the author’s description of the case study that those responsible for the project had not foreseen the political fallout of implementing the new system.
Lessons learned
I suspect the lessons the author draws from the case study will be depressingly familiar to many folks who have lived through a packaged software implementation. The main points made include:
- Senior management failed to consider the effect that the existing political tensions within the organisation would have on the project.
- There was no prior analysis of potential areas of concern that front line employees may have.
- There was a failure to recognize that the composition of a project steering committee will have political implications. Groups under-represented on the committee will almost always be resentful.
In short: new systems will almost always reconfigure relationships between different stakeholder groups. These reconfigurations will have political implications which need to be addressed as a part of the project.
Summing up
The paper details an interesting case study on the political effects of packaged software implementation, and although the paper was written well over a decade ago, many of the observations made in it are still very relevant today. I suspect many readers will find that author’s analysis and conclusions resonate with their own experiences.
The take-home lesson in a line is as follows: those implementing a packaged software system would do well to pay attention to existing relationships between different stakeholder groups and understand how these might be affected by the new system.
Eight to Late 