Archive for the ‘IT Management’ Category
Some perspectives on quality
Introduction
A couple of years ago, I wrote a post entitled, A project manager’s ruminations on quality, in which I discussed meaning of the term quality as it pertains to project work. In that article I focused on how the standard project management definition of quality differs from the usual (dictionary) meaning of the term. Below, I expand on that post by presenting some alternate perspectives on quality.
Quality in mainstream project management
Let’s begin with a couple of dictionary definitions of quality to see how useful they are from a project management perspective:
- An essential or distinctive characteristic, property, or attribute.
- High grade; superiority; excellence
Clearly, these aren’t much help because they don’t tell us how to measure quality. Moreover, the second definition confuses quality and grade – two terms that the PMBOK assures us are as different as chalk and cheese.
So what is a good definition of quality from the perspective of a project manager? The PMBOK, quoting from the American Society for Quality (ASQ), defines quality as, “the degree to which a set of inherent characteristics fulfil requirements.” This is clearly a much more practical definition for a project manager, as it links the notion of quality to what the end-user expects from deliverables. PRINCE2, similarly, keeps the end-user firmly in focus when it defines quality, rather informally, as, fitness for purpose.”
Project managers steeped in PRINCE and other methodologies would probably find the above unexceptional. The end-goal in project management is to deliver what’s agreed to, whilst working within the imposed constraints of resources and time. It is therefore no surprise that the definition of quality focuses on the characteristics of the deliverables, as they are specified in the project requirements.
Quality as an essential characteristic
The foregoing project management definitions beg the question:
Is “fitness of purpose” or the “degree to which product characteristics fulfils requirements” really a measure of quality?
The problem with these definitions is that they conflate quality with fulfilling requirements. But surely there is more to it than that. An easy way to see this is that one can have a high quality product that does not satisfy user requirements or meet cost and schedule targets. For example, many people would agree that WordPress blogging software is of a high quality, yet it does not meet the requirement of, say, “a tool to manage projects.”
Indeed, Robert Glass states this plainly in his book, Facts and Fallacies of Software Engineering. Fact 47 in the book goes as follows:
Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets or reliability.
So what is quality, then?
According to Glass quality is a set of (product) attributes, including things such as:
- Reliability – does the product work as it should?
- Useability – is it easy to use?
- Modifiability – can it be modified (maintained) easily?
- Understandability – is it easy to understand how it works?
- Efficiency – does it make efficient use of resources (including storage, computing power and time)?
- Testability – can it be tested easily?
- Portability – can it be ported to other platforms? This isn’t an issue for all products – some programs need run only on one operating system.
Note that the above listing is not in order of importance. For some products useability maybe more important than efficiency, in others it could be the opposite – the order depends very much on the product and its applications.
Glass notes that these attributes are highly technical. Consequently, they are best dealt with by people who are directly involved in creating the product, not their managers, not even the customers. In this view, the responsibility for quality lies not with project managers, but with those who do the work. To quote from the book:
…quality is one of the most deeply technical issues in the software field. Management’s job, far from taking responsibility for achieving quality, is to facilitate and enable technical people and the get out of their way.
Another point to note is that the above characteristics are indeed measurable (if only in a qualitative sense), which addresses the objection I noted at in the previous section.
Quality as a means to an end
In our book, The Heretic’s Guide to Best Practices, Paul Culmsee and I discuss a couple of perspectives on quality which I summarise in this and the following section.
Our first contention is that quality cannot be an end in itself. This is a subtle point so I’ll illustrate with an example. Consider the two “ends-focused” definitions of quality mentioned earlier: quality as “fitness for purpose” and quality as a set of objective attributes. Chances are that different project stakeholders will have differing views on which definition is “right”. The problem, as we have seen in the earlier sections, is that the two definitions are not the same. Hence quality cannot be an end in itself.
Instead, we believe that a better definition comes from asking the question: “What difference would quality make to this project?” The answer determines an appropriate definition of quality for a particular project. Implicit here is the notion of quality as an enabler to achieve the desired project objective. In other words, quality here is a means to an end, not an end in itself.
Quality and time
Typically, project deliverables – be they software or buildings or anything else – have lifetimes that are much longer than the duration of the project itself. There are a couple of important implications of this:
- Deliverables may be used in ways that were not considered when the project was implemented.
- They may have side effects that were not foreseen.
Rarely, if ever, do project teams worry about the long term consequences of their creations. Their time horizons are limited to the duration of their projects. This myopic view is perpetuated by the so called iron triangle which tells us that quality is a function of cost, scope and time (i.e. duration) of a project.
The best way to see the short-sightedness of this view is through an example. Consider the Sydney Opera House as an example of a project output. As we state in our book:
It is a global icon and there are people who come to Sydney just to see it. In term of economic significance to Sydney, it is priceless andi rreplaceable. The architect who designed it, Jørn Utzon, was awarded the Pritzker Prize (architecture’s highest honour) for it in 2003.
But the million dollar question is . . . “Was it a successful project?” If one was to ask one of the two million annual tourists who visit the place, we suspect that the answer would be an emphatic “Yes.” Yet, when we judge the project through the lens of the “iron triangle,” the view changes significantly. To understand why, consider these fun filled facts about the Sydney Opera House.
- The Opera House was formally completed in 1973, having cost $102 million
- The original cost estimate in 1957 was $7 million
- The original completion date set by the government was 1963
- Thus, the project was completed ten years late and over-budget by more than a factor of fourteen
If that wasn’t bad enough, Utzon, the designer of the opera house, never lived to set foot in it. He left Australia in disgust, swearing never to come back after his abilities had been called into question and payments suspended. When the Opera House was opened in 1973 by Queen Elizabeth II, Utzon was not invited to the ceremony, nor was his name mentioned…
Judged by the criteria of the iron triangle, the project was an abject failure. However, judged by through the lens of time, the project is an epic success! Quality must therefore also be viewed in terms of the legacy that the project leaves – how the deliverables will be viewed by future generations and what it will mean to them.
Wrapping up
As we have seen, the issue of quality is a vexed one because how one understands it depends on which school of thought one subscribes to. We have seen that quality can refer to one of the following:
- The “fitness for purpose” of a product or its ability to “meet requirements.” (Source: PRINCE2 and PMBOK)
- An essential attribute of a product. This is based on the standard, dictionary definition of the term.
- A means of achieving a particular end. Here quality is viewed as a process rather than a project output.
Moreover, none of the above perspectives considers the legacy bequeathed by a project; how the deliverables will perceived by future generations.
So where does that leave us?
Perhaps it is best to leave definitions of quality to pedants, for as someone wise once said, “What is good and what is not good, need we have anyone tell us these things?”
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.
The king’s son – a project management fable
Once upon a time there was a king who was much loved by his people. The people loved him because he did many Good Things: he built roads for those who needed to travel long distances, houses for those who lacked a place to live and even initiated software projects to keep geeks in gainful employment.
All the Good Things the king did needed money and although the king was rich, his resources were not unlimited. Naturally, the king’s treasurer wanted to ensure that the funds flowing out of the state coffers were being put to good use.
One day, at a council meeting the treasurer summoned up his courage and asked the king, “Your highness, I know your intentions are good, but how do we know that all the money we spend is being used properly?”
“It must be so because the people are happy,” replied the king.
“Yes they are happy and that is good,” said the treasurer, “but how do we know that money we spend is not being wasted? Is it not possible that we could save money by coordinating, planning and monitoring the Good Things we do in an organized manner?”
The king (who was known to think from time to time) mulled over this for a few days.
After much mulling, he summoned his treasurer and said, “You are right. We should be more organized in the way we do all the Good Things we do. This task is so important that I will ask my second son to oversee the Good Things we do. He is, after all, a Prince Too.”
The second son (who was a Prince Too) took to his new role with relish. His first act was to set up a Governance Committee to oversee and direct all the Good Things that were being done. He ordered the board to come up with a process that would ensure that the Good Things being done would be done in an efficient and transparent way. His second act was to publish a decree, declaring that all those who did not follow the process would be summarily terminated.
Many expensive consultants and long meetings later, the Governance Committee announced they had a methodology (they could coin a word or two…) which, if followed to the letter, would ensure that all the Good Things being done were done efficiently, in a way to ensure value for the state. They had the assurance of those expensive consultants that the methodology was tested and proven so they believed this would happen as a matter of course. Moreover, the rates that the consultants charged convinced the Governance Committee that this must indeed be so.
In keeping with penchant of committees to name things, they gave the methodology the name of the king’s son (who, as we have seen earlier, was a Prince Too).
And so it came to pass that all the Good Things being done followed a process. Those who managed the Good Things and those who actually did them, underwent rigorous training in the foundations and practice of the methodology (which meant more revenue for the consultants). The planners and the doers then went out and applied the methodology in their work.
And for a while, everyone was happy: the king, the treasurer, the Governance Committee ….and of course, the Prince Too.
After sometime, however, the treasurer noticed that the flow of money out of his coffers and into the Good Things had not lessened – on the contrary, it seemed to have increased. This alarmed him, so he requested a meeting with the king’s son to discuss the matter. The king’s son, on hearing the treasurer’s tale, was alarmed too (his father would not be happy if he heard that methodology had made the matter worse…).
The king’s son summoned the Governance Committee and demanded an Explanation Now! Yes, this was how he said it, he was very, very angry.
The Governance Committee were at a loss to explain the paradox. They were using a tested and proven methodology (as the expensive consultants assured them), yet their cost of all the Good Things they were doing was rising. “What gives?” they wondered. Try as they did, they could not find an answer. After much cogitation they called in the expensive consultants and demanded an explanation.
The consultants said that the methodology was Tested and Proven. It was simply not possible that it wasn’t working. To diagnose the problem they recommended a month long audit of all the Good Things that had been done since the methodology was imposed.
The Governance Committee agreed; they had little choice (unless they preferred summary termination, which they didn’t).
The audit thus proceeded.
A month later the consultant reported back to the Governance Committee. “We know what the problem is,” they said. “Those who do Good Things aren’t following the methodology to the letter. You must understand that the benefits of the methodology will be realised only if it is implemented properly. We recommend that everyone undergoes refresher training in the methodology so that they understand it properly .”
The Governance Committee went to the treasurer, explained the situation and requested that funds be granted for refresher courses.
On hearing this, the treasurer was livid. “What? We have to spend more money to fix this problem? You must be joking.” He was very angry but he could see no other way; the consultants were the only ones who could see them out of this mess.
The money was sanctioned and the training conducted. More Good Things were done but, unfortunately, the costs did not settle down. Things, in fact, got so bad that the treasurer went directly to the king and mentioned the problem.
The king said, “Summon my second son,” he said imperiously, “I must have Words with him.”
The second son (who was a Prince Too) was summoned and arrived post-haste. His retainers had warned him that the king was very very angry.
“Father, you requested my presence?” He asked, a tad tremulously.
“Damn right, I requested your presence. I asked you to ensure that my money is being well spent on creating Good Things, and now I find that you are spending even more than we did before I put you in charge. I demand an explanation,” thundered the king.
The king’s son knew he was in trouble, but he was a quick thinker. “Father,” he said, “I am as disappointed as you are with the performance of the Governance Committee; so disappointed am I that I shall terminate them summarily.”
“You do that son,” said the king, “and staunch the flow of funds from my coffers. I don’t know much, but I do know that when the treasurer tells me that I am running out of money, I have a serious problem.”
And so the Governance Committee was terminated. The expensive consultants, however, lived on as did the king’s son (who was after all a Prince Too ). He knew he would try again, but with a more competent Governance Committee. He had no choice – the present bunch of incompetents had been summarily terminated.
Acknowledgement
This piece was inspired by Craig Brown’s New Prince2 Hypothesis.
Eight to Late 