Archive for the ‘Project Management’ Category
Capturing and using knowledge in project-based organisations
Many organisations find it hard to capture and use knowledge effectively. This problem is especially acute in project-based organisations because project teams – the primary “generators” of knowledge in such organisations – are temporary structures which are disbanded when a project’s completed. Hence most project-based organisations emphasise (and enforce!) the capture of knowledge through end-project activities such as project post-mortems, documentation etc.
That’s fine as it goes, but capturing knowledge is only a part of the story. There is the other (not so small) matter of using it. Here’s where most efforts fall flat – all that supposedly useful knowledge is rarely used. This is the point addressed by Katrina Pugh and Nancy Dixon in a short note entitled, Don’t Just Capture Knowledge–Put It to Work, published in the May 2008 issue of Harvard Business Review. Pugh and Dixon suggest using what they call a knowledge harvest– an approach aimed at capturing knowledge and putting it to use. In brief, a knowledge harvest consists of:
-
Identifying those who might find the knowledge useful. Pugh and Dixon call these people knowledge seekers. These folks are interested in the knowledge on offer and so already have the motivation to learn. In projectised organisations, programme managers have a broad view of project activity, and can thus help identify suitable seekers to participate in knowledge capture (or harvesting) sessions.
-
Involving knowledge seekers in harvesting sessions. The idea here is that seekers, being self-motivated, will ask pointed questions aimed at extracting information that is often left out of typical post-project documentation. They might, for instance, ask probing questions regarding what went wrong and why; points that are often glossed over for political or other reasons.
In their note, Pugh and Dixon present a case study where this method was used successfully in a project situation. Following the initial success of the technique, it has been adopted by other programmes within the organisation that was the subject of the study.
This simple technique has much to commend it. For one, conversation is a more effective way (than documentation) to get at tacit knowledge. The presence of knowledge seekers at harvest sessions improves chances that the right questions – i.e. those that “tease out” tacit knowledge – will be asked. Secondly,the captured knowledge will almost certainly be used since seekers are identified by their interest in what’s on offer. Finally, if seekers find the knowledge gained to be useful on their own projects, they’ll pass it on to other seekers in harvesting sessions down the line, thus ensuring what’s learnt becomes a part of organisational memory.
Appstronauts
Eliciting and documenting application requirements is hard work. It’s made even harder if one is dealing with an appstronaut. “So who or what’s an appstronaut?” – I hear you ask. Here’s a definition, along with some explanatory notes:
Appstronaut (noun): a person who can hold forth for hours on the big picture, but cannot (will not!) get down to details.
Distribution: Generally found in upper echelons of management, but sightings have been reported at other levels too.
Field notes: Appstronauts are characterised by verbosity coupled with a short attention span. They exhibit extreme fondness for strategy, vision and all that “big picture” stuff, but have little patience for details. They are known to have good ideas, but generally lack the focus to see them through to fruition.
Appstronauts infuriate analysts, who need nitty-gritty details in order to understand and document application requirements. The big picture stuff, as fascinating as it is to the appstronaut, is simply of no use to the analyst. But, if left unchecked, appstronauts will be content to float around at rarefied heights where ideas are thick, but details thin. Analysts charged with compiling application requirements must bring them down to earth. But, how? This post aims to answer the question by highlighting some simple techniques to tether appstronauts to reality.
Without further ado, here they are:
- Start by zooming in on a small part of the big picture: The main problem is that the canvas painted by appstronauts is way too big. A practical way to start filling in detail is by focusing on a part of the picture and drilling down to specifics. Which part? The answer should be clear from the appstronaut’s spiel. In brief: the part should be important yet easy enough to action or implement. It may be something that ties into existing systems, for instance. What the analyst should look for is a quick win. Something that can be built quickly, but also provides value to the appstronaut.
- Contribute to the picture by painting a part of it: The best analysts understand the business thoroughly. Given this, they should be able to contribute to the appstronaut’s vision. In fact, I have sat through meetings where smart analysts have steered the discussion (with tact!) in productive directions. At this point the analyst is contributing to the vision too.
- Help appstronauts drill down to specifics: Appstronauts abhor details; analysts thrive on them. The analyst’s job is to get appstronauts to talk about specifics. To do this, it can be helpful to send out a list of questions before the meeting so that appstronauts come in prepared. Very often, they’ll throw up their hands and say, “It’s your job to fill in the details.” At this point the analyst has to gently, but firmly, insist that details of business requirements have to come from (no surprise!) the business.
- Verify mutual understanding: It is important to verify that both parties – the appstronaut and the analyst – have a common understanding of what transpires in a requirements analysis session. This should be done both during and after the meeting. During the session the analyst should, by asking appropriate questions, check that their understanding of the requirements is correct . After the session, a compilation of notes should be sent out, asking users to send their corrections and comments within the next day or two. This gives them a chance to make any revisions before work on documenting the requirements is started. This is standard practice in requirements elicitation, but is absolutely critical when one is dealing with an appstronaut (remember the “short attention span” bit in the field notes above)
- Use visual aids (screen mock-ups, process diagrams etc.) liberally: This applies both to the analysis sessions and the documents. Often, in requirements sessions I use the whiteboard to sketch process flows, relationships and even app screen layouts. Any documents or presentations should have lots of visuals as appstronauts have even less patience than others to go through large swathes of text.
After bagging appstronauts through most of this piece, I should acknowledge that they can play a key role in driving important business initiatives. As mentioned in the field notes above, they often have good ideas but need some help implementing them. This is where the analyst comes in: he or she is very familiar with the business and/or associated systems, and is thus well placed to help appstronauts add substance to their grand, but ethereal, visions. If approached constructively, working with appstronauts can be an opportunity instead of a trial.
A project manager’s ruminations on quality
And what is good, Phædrus,
And what is not good…
Need we ask anyone to tell us these things?
…so runs the quote at the start of Robert Pirsig’s philosophical novel, Zen and the Art of Motorcycle Maintenance. In the book, Pirsig introduces his ideas on the metaphysics of quality in which he argues that quality is undefinable because it precedes analysis. Or, to paraphrase the quotation above: when we see something good (i.e of high quality) we just know it is good without having to analyse what makes it so. When I read the book some years ago, it seemed (to me at any rate) that Pirsig was using the term “quality” in a different and expanded sense from its usual meaning(s). Experience also confirms that using the word in any discussion leaves one open to being misunderstood because it means different things to different people. This brings me to my point: it is important for project managers to ensure that all stakeholders have a common understanding of quality. I expand on this thought below, drawing on what leading project management frameworks – PMBOK and PRINCE2 – have to say about quality.
It is worth starting with a couple of dictionary definitions of quality, if only to show how worthless they are from a project manager’s perspective:
1. An essential or distinctive characteristic, property, or attribute.
2. High grade; superiority; excellence
Not much help, right? In fact, it’s even worse: the second definition confuses quality and grade – two terms that 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.”
The PMBOK/ASQ definition of quality, through its use of the word “degree”, suggests that any measure of quality should be quantitative – i.e. there should be a number associated with it; or, if not a number, at least a qualitative measure of quantity (high, medium, low, for example). PRINCE2 also insists on measurability through its notion of customer quality expectations and acceptance criteria, the former being high level, qualitative specifications and the latter quantitative, testable quality criteria. Although PMBOK does not formalise customer quality expectations, both methodologies insist on measurable quality criteria being defined as early in the game as possible. Basically these should be aimed at answering the question: how will end-users know they’ve got what they asked for?
Any project management methodology (including informal or homegrown ones!) must include processes that deal with quality. As might be expected, both PMBOK and PRINCE2 accord great importance to it. Quality Management is one of the nine knowledge areas in PMBOK. Further, PMBOK explicitly acknowledges that project quality is affected by balancing the three fundamental variables of scope, time and cost. In PRINCE2 quality is built in to a project up-front: right from start up (pre-initiation) through to initiation, product delivery and close. However, despite superficial differences in their approaches, both PMBOK and PRINCE2 treat quality in much the same way. Both emphasise the need to plan for quality at the outset (quality planning), put processes in place to ensure quality (quality assurance) and finally test for it when the deliverables (products in PRINCEspeak) are completed (quality control / quality review).
Regardless of your persuasion – or even if you’re a methodology agnost like me – quality is something you have to worry about on your projects. Project managers, unlike Pirsig, cannot afford to leave quality undefined. So, if your end-users’ eyes glaze over when they are asked about their quality expectations, understand it’s only because they don’t know what you mean; quality means different things to different people. Instead, ask them how they’ll know what is good and what is not good, and be sure to pay very close attention to what they say in reply.
Eight to Late 