Home Project Management General Practical Project Management A Guide on How to make Projects Work : Part 2
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
A Guide on How to make Projects Work : Part 2 Print
Many projects fail because of the simplest of causes. You don’t have to be a genius to deliver a project on time, nor do you have to be steeped in a mystical project management methodology to be a project manager... We continue the serialisation of A Project Management Primer by our intrepid traveller Nick Jenkins (c) 2005  http://www.nickjenkins.net

S c o p e

You have to know what you are trying to do.

This seems obvious, but lack of clarity in the early stages of a project is very common and causes many problems. Many projects start up with vague or ill defined ideas of what they want to achieve. If you hope to deliver a successful project in a finite amount of time you need to determine the final state your product must achieve, you need to set yourself a concrete goal.

If you have an infinite amount of time you could simply try one solution after another until you hit upon the best solution for your problem. This ‘inventive’ approach to product development can give rise to spectacular and unique solutions but more often than not ends in failure or inadequate results. Also most of us don’t operate in environments where we have infinite amounts of time or resources. Most of us operate in an environment where we need to deliver a concrete in solution in a very finite period of time.

In order to do this we need a way to select the best solution from a range of possible approaches. The first and most important step in this process is defining what will actually constitute a success. Then we can evaluate all of the possibilities against our definition of success and find the best fit. Without this we’ll be shooting in the dark.

The more accurate you can be about defining your objectives, the more likely you will be to succeed.

Scope, Visions and Goals

Scope is a general term to describe everything that your project encompasses, everything that must be achieved for the project to be complete. This would encompass your vision, your goals and your requirements and would be embodied in documents such as a “project proposal” and at a lower level “commercial specifications” and “technical specifications”.

The word ‘vision’ produces shudders in technical and non-technical people the world over. And rightly so, for a vision is normally a collection of meaningless catch phrases and marketing dribble intended to dupe people into thinking that businesses are there for polite and altruistic reasons.
This is not the kind of vision I mean.

When I talk about vision I’m simply saying that you need a single encapsulated idea which defines the aim of your project. Why are you doing the project in the first place ? A project is a standalone task (or set of tasks) that has an intended outcome. You work on your project, complete it and then move on to the next.

If you can’t state the aim of your project in a single sentence, then it’s not a project.

Maybe it’s an occupation, an idea for a business or possibly a way of life but it's not a project. It might even be a program, a set of projects that need to be divided into single ‘efforts’. A project is a defined task with a finite life with a fixed end point and that end is defined by your ‘vision’.

Without a single, linking goal all the dependent steps of project planning become difficult. That single vision may be broken up in sub-goals but it provides the link that holds all of the disparate parts of the project together into a single enterprise. It gives your team and stakeholders a sense of purpose and defines the success of your project.

Goals are slightly lower-level and more specific than the vision. Goals should directly support the overall vision of the project but refine its definition. Typically goals are set out by customers or by a business and define how the success of the project will be achieved. While the vision encompasses the whole project, goals may refer only to the objectives of a particular segment of the project.

Note that the terms scope, vision and goal are largely interchangeable. Different organisations use them in different contexts to refer to much the same concepts. The definitions set out here are the most commonly used versions. Use the version most appropriate to you and your organisation.

The Vision as Inspiration

While further steps in the project planning aim to be more and more specific the initial goal should be broad enough to encompass the whole project. The vision must state, succinctly, the ultimate goal for the whole project.

The goal or vision should also be inspiring or, appropriately enough, “visionary”.

Goals like : “To deliver the cheapest system, in the shortest time, that just about gets the job done” are unlikely to inspire anyone or motivate a team.

On the other hand a goal like : “Deliver the best sales and marketing system on the market” is more likely to inspire personal commitment from the team and stakeholders.

If you are working on your own, an inspirational vision can restore your flagging enthusiasm. When the client or manager calls you up for the Nth time and says “Where’s that bit of documentation I asked for?” and you say to yourself “Why am I doing this again?” – your answer could be “because I’m writing the best damn <insert name> the world is ever going to see!”.

Visions don’t have to be written down or cast in stone. They don’t even have to be formalised in any particular sense. In large organisations they often are, since that’s the kind of the thing large organisations like to do,. The only important thing is that you, your team and your stakeholders know exactly what the vision is and agree on it.

Don’t go overboard. Now is not the time to exercise your commercial-buzzword vocabulary. Select language that is natural and easy for you to use and that sounds sincere. The more you believe the vision and the more you use it, the more that other people, including your team and your customers, will come to believe it too.

One of the most important things you can do is to inspire trust in the people you work with. It is human nature to be sceptical and it is easier for most people to assume that a project will fail rather than assume it will succeed. You don’t have that luxury however!

Everybody from the team to the stakeholders to the man signing the cheque will want reassurance that you know what you are doing. You have to build confidence in yourself and in the project. Pick a vision that inspires! If it inspires you, it will probably inspire them as well.

Often the vision will be delivered into your hands by your executive sponsor or a client that commissions your project. In discussions with them you will notice that they have a singular way of referring to the project such as “we want a sales and marketing system that’s going to save us time and money”. You could do worse than adopt a phrase like that as a vision but consider reworking it to suit your own purposes.

Goals as a Filter for Requirements

One of the primary purposes of goals is to act as a filter for subsequent requirements.
If a particular requirement cannot be traced back through higher-level goals to the overall project vision then it should be dropped since it will be outside the scope of the project.

For example, if the overall vision for the project was to “Deliver the best sales and marketing system on the market” an appropriate sub-goal might be “to deliver a sales-order processing system for use throughout all international offices”. An inappropriate sub-goal would be “to deliver an invoicing system” since the invoicing system would be part of the financial system and not the sales system.

This process of filtering should be used throughout the the project to assess requests for extra functionality and to consider them for inclusion within the project. The use of such filtering techniques gives you a method with which to avoid the perils of “scope creep”.


The link between low and high level goals can be fundamentally important. By linking them together you can track your progress through the objectives of your product. By delivering low level goals you build up to the delivery of high level goals and ultimately the delivery of the completed project.
This is known as traceability.

A Decent Proposal

Sometimes referred to as a ‘business case’, the project proposal states the highest level goals in a project. It outlines the overall business goals and vision for the project as decided by the customer or client. It is sometimes drawn up well before the project starts although you may (if you are lucky) also get a hand in its creation.

The basic proposal should contain the vision for the project and the business goals, what your client hopes to achieve at a business level. There may also be a large amount of supporting information in order to qualify or corroborate the stated goals but the goal itself should be clear.
The supporting information might include preliminary forms of the project planning documents, such as budgets, schedules and so forth.

Project proposals are often vital documents because they are what gets signed off when a commercial deal is agreed. As such you need to consider them carefully because they may be define what your are legally committed to delivering.

On the next page is an example based on our hypothetical sales and marketing system. The vision is stated first and after that a list of specific business and technical goals is listed. Each of the specific goals contributes directly to the vision of delivering the sales and marketing system.

Whizz-Bang Customer Relationship Mangling System

The project should deliver the best Customer, Sales and Marketing system on the market, it should :

• Reduce time taken to process sales orders by 50% (of manual process times)
• Provide detailed management reports on a quarterly basis
• Provide detailed market and customer analysis at request
• Link sales directly to marketing initiatives to measure marketing ROI
• Provide detailed client and prospect information to account managers
• Completely automate licence renewals via a website
• Provide a zero-footprint client, accessible via the Internet
• Provide an upgrade path for users of other sales order systems

You will note that this is not long or overly detailed. It provides an adequate framework for moving the project forward without getting bogged down in detail. The goals outlined will probably be supported by a fair amount of commercial and market research but within the context of the project, the above should be more than adequate. The level of detail will depend on the size and importance of your project to the organisation.

You should also note that some goals are more specific than others. For example “reduce time taken to process sales orders by 50%” is a fairly specific, readily testable goal. On the other hand “provide detailed management reports on a quarterly basis” is a little bit vague. What kind of reports? In what format? For whom?

Although more detail is desirable it is probably not necessary at this stage. The broad goals have been laid out and it will be the purpose of subsequent phases (like requirements specification) to define how they will be achieved.

Spend enough time on your proposal to make sure it is accurate and succinct. It will be the yardstick against which senior management will judge the success of your project. Don’t spend so much time on it that you delay the commencement of the project proper.

Return on Investment

One important component of many formal business cases is a ‘Return on Investment’ or ROI calculation. Simply put an ROI calculation compares the cost of a project with the benefits you expect to achieve. Different projects can then be evaluated on a like-for-like basis and the best use for the money selected.

Obviously to compare costs to benefits they need to be stated in the same ‘units’ and not surprisingly these are usually “dollars”. This is where the problems start. The cost of a project is usually fairly easy to determine but the benefits can be much harder to quantify. Benefits are usually determined by asking the customer to estimate what benefits, in dollar terms, they hope to achieve through using the product.

This could range from freeing up someone from a manual process (saving money) to attracting more customers. These are fairly easy to put a dollar figure to but are based on future predictions which can be unreliable. For example how many hours of someone’s day will you free up ? How many more customers will this product attract ?

Sponsors tend to inflate predicted returns in order to get 'their' project up and running. They will confidently stick a finger in the air and predict a 50% increase in customer numbers if the project is delivered correctly. While it is not primarily your problem, you might be lumbered with unrealistic expectations for your project. You might also be lumbered with the blame for 'not implementing the project properly' when it fails to deliver the expected returns. Fortunately most companies are terrible at actually comparing expected results with actual results.

Notwithstanding this, if you can confidently estimate one of these values you can then compare your costs to your benefits. Your return on investment is the ratio between the costs and the benefits with a positive ratio indicating profit, or a return on your investment. This is normally done over an extended period of time to determine when the product will reach its ‘payback’ point.

For example if I decide to make a terrific new product which would help me breed marmosets, I could work out the ROI like this :

1. I estimate that it will take me roughly six weeks to design, develop and debug my product.
I will also need a new PC costing about $2000 and some important marmoset measuring equipment costing about $500. I also pay myself about $500 a day, so the cost would therefore be : 30 working days x $500 + $2500 hardware = $17 500

2. By surveying my prospective market I determine that there are about 1000 marmoset breeders in my local area. I estimate that I will reach about 10% of them the first year, then as my fame catches on I will sell to another 30% of them and then as competing products come on the market sales will decline back to a steady 10% per year.

Since marmoset breeders aren’t rich I decide to charge about $50 a copy for my software giving me the following benefit calculation :
10% of 1000 is 100 x $50 = $5000 in the first year
30% of 1000 is 300 x $50 = $15000 in the second year
10% of 1000 is 100 x $50 = $5000 in the third and successive years

3. My ROI calculation thus looks like this :

return on investment

Based on this calculation my product will reach payback in 1 year and 10 months. Not bad for something that only took six weeks to write!


Requirements specification is the process of refining the goals of a project to decide what must be achieved to satisfy the 'customers'.

Sometimes requirements specification takes place before the formal commencement of a project to help identify and select the right for a solution and technology. Often this is known as a feasibility study or project analysis. More typically however some requirements are thrown together (maybe in a proposal) and the real requirements specification occurs only after the project has started.

Functional Requirements

Functional requirements are the obvious day-to-day requirements which end-users and stakeholders will have for the product. They revolve around the functionality that must be present in the project for it to be of use to them.

A functional requirement typically states as “the system X must perform function Y”. This is known as an ‘assertion’. An assertion asserts or affirms a necessary or desirable behaviour for the system or product in the eyes of a stakeholder.

Without clear assertions requirements are nothing more than vague discussions which have a regrettable tendency to clutter up your desk and your mind.

Compare the two following, contrasting, functional requirements:

• The financial system must produce a detailed customer invoice as per Appendix A.
• Producing an invoice for customers is important. Invoices should contain all the pertinent information necessary to enable a customer to supply payment for goods.

The first is a functional requirement stated as an assertion. It indicates that the financial system is responsible for producing a detailed customer invoice which contains all the information in Appendix A. While it could be more specific, the reader is left in no doubt as to what the financial system must do in order to be a successful financial system.

The second could be the introduction for a chapter in an accounting book. Although it states that invoices are important it gives no indication of who or what is responsible for producing them. It then rambles on about what goes in an invoice which everyone already knows anyway. Such a statement does not belong in a requirements specification.

The second ‘requirement’ compounds the problem by looking solid but really being vague and ambiguous. What does pertinent information mean? To enable a customer to supply payment is superfluous since that's what an invoice is for. The statement, while accurate, contributes nothing towards our understanding of what the system must do to be successful.

Here are some more ‘better’ statements of requirements:

• A customer account record must contain a unique account reference, a primary contact name, contact details and a list of all sales to the customer within the past sales year

• Contact details must consist of a phone number, an address and an optional email address

• For each contact up to five separate phone numbers should be catered for

Non-Functional Requirements

It is essential to consider other requirements too, these are called “non-functional requirements” which, to my mind, is a bit of an oxymoron. The point however is valid, there are 'obvious' requirements that your end-users may not think about it.

Performance - Performance covers areas like responsiveness, throughput and speed of operation. What is the minimum performance that will satisfy your client ?

Usability - How “easy-to-use” will the finished product be ? For example do you cater for disabled or handicapped users ? Generic ease of use should be considered though, more than one product has failed by supplying full functionality with an obscure or convoluted interface.

Reliability - Reliability requirements deal with the continuous availability of the product to users. They should state what availability is necessary and desirable.

Security - In products which deal with confidential or sensitive information, security considerations should be taken into account. Requirements for different levels of access, encryption and protection should be gathered.
Financial - Financial considerations which will determine the success or failure of the project. For example a bank or investor might specify certain financial constraints or covenants which must be satisfied during the project.
Legal - There may be legal requirements that must be met due to the environment in which your product will operate. Consult a legal expert for these.
Operational - There may be a number of day-to-day operational issues that need to be considered. Failure to accommodate these will not delay project launch but may limit or halt its uptake by end-users once it has been launched.
Specialist - There might be special requirements that are dependent upon the nature of the project or the nature of the business. You should considered these separately and state them explicitly in design docs.


Stakeholders are an integral part of a project. They are the end-users or clients, the people from whom requirements will be drawn, the people who will influence the design and, ultimately, the people who will reap the benefits of your completed project.

It is extremely important to involve stakeholders in all phases of your project for two reasons.
Firstly, experience shows that their involvement in the project significantly increases your chances of success by building in a self-correcting feedback loop. Secondly, involving them in your project builds confidence in your product and will greatly ease its acceptance in your target audience.

There are different types of stakeholders and each type should be handled differently :

Executive - Executive stakeholders are the guys who pay the bills. Typically they are managers or directors who are involved with commercial objectives for the project. They should restrict themselves to commercial considerations and be actively discouraged from being involved in technical design, their experience and skills are vastly different to that of 'typical' end-users.

End-user - These are the guys that are going to use your product.
No one knows more about what the product is supposed to do when it hits their desks than they do. No one ! Including you ! You may think you know better but if you don't listen to them you're kidding yourself.

Expert - Sometimes you need input from experts in other fields. People like graphic designers, support reps, sales or lawyers and accountants.

Requirements capture

Requirements capture is the process of harvesting the raw requirements of your stakeholders and turning them into something useful. It is essentially the interrogation of stakeholders to determine their needs. This can take many forms, with questionnaires or interviews being the most popular.
The usual output is a 'requirements specification' document which details which of the stakeholder requirements the project will address and, importantly, which it will not.

The focus in requirements capture must be in gathering of information. Keep your ears open and your mouth shut! Listen carefully to what people want before you start designing your product. Later you can focus on how things are to be achieved for now you need to find out what must be achieved.

In reality this is difficult to achieve. Technical people complain that stakeholders often “don't know what they want”. This is not true. Stakeholders know exactly what they want – they want less hassle, easier jobs and so on. The problem is that they can't design the system for you, they can't tell you how to achieve what they want. The trick in requirements specification is to take what the stakeholders give you and distil it into something you can use to help you make decisions on how to implement their wishes. One way to think of this is as finding the ideal solution to the stakeholder’s current problems.

Requirements capture also needs to be fast. Projects have a tendency to bog down at this stage and to produce reams of documentation, but no useful output. Requirements capture should not produce endless tomes detailing the answer to every possible question but should provide enough clarity for the project team so that the objectives are clear.


Questionnaires are a typical way of gathering requirements from stakeholders. By using a standard set of questions the project team can collect some information on everyone's needs. While questionnaires are efficient for rapidly gathering a large number of requirements their effectiveness can be limited since it is a one way process. If you don't ask the right questions, you don't get the right answers. There is also no way to seek clarification or resolve conflict. To resolve this, questionnaires are usually used in conjunction with other methods, such as interviews.


The same questions posed in a questionnaire can be put across a table in an interview. The benefit of the interview is that it allows more exploration of topics and open ended discussion on the requirements for the project. It's a two way process.

Interviews can either be structured as single or group sessions. Particular stakeholders can be interviewed individually or a group session can be used thrash out ideas amongst a larger number of stakeholders (and hopefully obtain consensus). In a group session you can use a formal structure or a more open style where ideas are thrown around, a brainstorming session. The best ideas that survive can be adopted by the project team as part of the requirements.

The down-side to interviews is that they are time and people intensive. Not only must the interview be set up and conducted but minutes must be taken, distributed and reviewed, and it may be necessary to hold one or more follow-up meetings. Using questionnaires and interviews is a common and efficient practice; questionnaires can be distributed beforehand and an overview of the stakeholder’s requirements collected. The interviews are then focussed and directed towards the clarification of those requirements.

User observation

Another method of requirements capture is direct end-user observation or evaluation.

The purpose of user observation is to capture requirements that the end-users may not be consciously aware of. For example individuals using a cheque processing system in a large finance system may conduct a number of manual steps outside of the system that could be automated.
Because they don’t regard these steps as being part of the system they will not mention them when questioned about the incumbent system. Only by direct observation will the development team become aware of the importance of these steps.

You can either use free-form observation or you can take a typical group of end users are set a series of tasks and monitor their processing of these tasks. Notes are made on the way they conduct the tasks, any obstacles they encounter and you could even video tape it (if they agree).

Direct user observation is particularly powerful because, unlike the first two methods of requirements capture, it relies on observed fact and not upon opinions. It is however, the most resource intensive of the three techniques.

Conflicting Requirements

One or more requirements may contain elements that directly conflict with elements of other
requirements. For example, a performance requirement may indicate that a core system must be
updated in real time but the size and scope of the system (as defined by other requirements) may
preclude this. Updating such a large system may not be possible in real time.

One of the most effective ways of resolving conflicts between requirements is to impose some form of prioritisation. This allows the potential for negotiation since it provides a basis for assessing conflicting requirements. For example if, from the previous example, the requirement for real time updates was rated at a much higher priority than the inclusion of full customer data, then a compromise could be reached. The main ‘online’ database could contain only the barest essential of customer details (allowing real time updating) and a separate ‘archive’ database could be established which contained customer histories.

Requirements are often heavily interlocked and much of the time it seems your stakeholders have diametrically opposed points of view and cannot come to terms. If you pick apart any set of requirement however you can come to some sort of compromise with both parties and achieve consensus. This can be a difficult and even emotional process.

The very best way I have seen to resolve conflicting requirements works like this :

1. The stakeholders draw up a list of their requirements
2. The list is organised in strict priority order with the most important at the top, down to the least important at the bottom.
3. The project team then looks at the schedule and draws a line through the list based upon what they believe they can deliver with the time/money available
4. The stakeholders assess the development position and can then re-prioritise their requirements if required or negotiate over the nature and importance of requirements 5. Once consensus has been achieved both sides sign-off and work starts This is not a simple or easy way to achieve consensus however. Even the basic ordering of the list of requirements is no mean feat in a project of any size.

Documenting Requirements

You need a way of documenting your requirements for your project team. Stakeholders are also often asked to sign off their requirements as a confirmation of what they desire. Often this is where money starts to change hands.

Documenting requirements is much more than just the process of writing down the requirements as the user sees them. The requirements specification is an essential link in the total design of the whole project and attempts to give meaning to the overall goals of the project.

Whatever form of requirements documentation is used it should cover not only what decisions have been made but also why they have been made. Understanding the reasoning that was used to arrive at a decision is critical in avoiding repetition. For example, if a particular feature has been excluded because it simply is not feasible, that fact needs to be recorded. If it is not, then the project risks wasted work and repetition when a stakeholder requests the feature be reinstated later in the project.

Documenting the decision process is also useful from a stakeholder's point of view. It allows the stakeholders to better understand what to expect from the final product. A basic statement of
requirements without any underlying discussion can be difficult for a layman or end-user to understand.

SMART requirements

One useful acronym for defining requirements is SMART :

Specific A goal or requirement must be specific. It should be worded in definite terms that do not offer any ambiguity in interpretation. It should also be concise and avoid extraneous information.

Measurable A requirement must have a measurable outcome, otherwise you will not be able to determine when you have delivered it.

Achievable A requirement or task should be achievable, there is no point in setting requirements that cannot realistically be achieved.

Relevant Requirements specifications often contain more information than is strictly necessary. Be concise and coherent.

Testable To be of value requirements must be testable. You must be able to prove that the requirement has been satisfied. Requirements which are not testable offer no way to determine if they have been delivered.

The Language and Layout of Requirements Specifications

Requirements specs. have multiple audiences. They are used by the project team to deliver the project, and they are used by stakeholders to verify what is being done. While I advocate including contextual information to illustrate why a particular decision was taken there needs to be some way of easily separating the discussion from the “assertions”.

So I apply the following rules of thumb:

• For each requirement there should be an “assertion”; in essence, a decision
• Where assertions are documented they should consist of a single sentence which
states what a product “must” or “should” do.
• “Must” indicates a necessary requirement / “should” indicates a “nice-to-have”.
• There must be simple (visual) way to distinguish assertion from discussion

Below is an example with some discussion and the assertion highlighted with italics:

1.1 Usability – usability of the system is seen as very important to adoption of the system. The client raised some concerns about the time scales required to implement usability testing but the project team as a whole supported extending the time line for the development phase to include usability testing.
The system must be simple and easy to use and must follow the standard UI style as laid out in the company design handbook.

In this case the discussion is preserved for future reference but the requirement stands out distinctly from the body of the text. A project member reading the specification can skip through it and pull out the requirements quickly and easily. A manager reading through the document can do the same but also can review the context of the decision to understand how it came about.

Sometimes classification of requirements is made using the MoSCoW rules:

Must-haves are fundamental to the project’s success

Should-haves are important, but the project’s success does not rely on these

Could-haves can easily be left out without impacting on the project
Won't-have-this-time-round can be left out this time and done at a later date


I feel that the distinction between “should have” and “could have” is never clear and is usually the subject of much debate between client and project manager so I normally omit “could have”.
Every requirement then either becomes necessary (“must have”) or optional (“should have”).

Diagrammatic Methods

While you can specify specification in textual form, more graphical methods are available. As the saying goes, a picture is worth a thousand words, and this is both a blessing and a curse. While representing information with a picture or diagram can be extremely informative it can also be extremely confusing. Diagrams can often imply requirements without actually stating them and leave details open to interpretation.

For this reason I see graphical methods as supporting standard textual methods of description.
They should be used wherever appropriate, where the graphical nature of a representation will
more closely represent the nature of the requirement. If you find it difficult to explain in words the nature of a particular structure or process then by all means insert an appropriate diagram.

The emphasis must be on concise, accurate representations, so use whatever combination of graphical and textual elements seems right to you.


A Sample Requirements Specification

The most common method is to break down the requirements in an outline fashion as used in a document or manual.

For example:


1.0 Current product status – all parties highlighted the need for a clear and public indicator of the current status of a product

2.0 Dates - dates for each major milestone were also recognised as necessary. Although some of these dates will remain in the public domain others will be available only to “private” users. Private users will have the ability to publicise dates as they see fit.The dates specified are:

2.1 Development sign off

2.2 Testing sign off…


Even more structure can be put into the document by splitting up requirements categories :


For example:

1. Functional Requirements
1.1. Product list – the system should produce a list of products available or under

1.2. Current product status – all parties highlighted the need for a clear and public
indicator of the current status of a product. There should be a simple flag which
indicates at-a-glance whether the product is ready for release.

1.3. Dates – for each product, dates for each major milestone must be shown.
Although some of these dates will remain in the public domain others will be
available only to “private” users. Private users should have the ability to
publicise dates as they see fit.
The relevant dates are listed below:

1.3.1. Design sign off

1.3.2. Development sign off

1.3.3. Testing sign off

1.3.4. etc…

2. Non-Functional Requirements

2.1. Performance – the system must be updated daily and information available to all
international users within 1min of the information being posted by head office.

2.2. Usability – usability of the system was seen as very important to adoption of the
system. The system must be simple and easy to use and must follow the
standard UI style as laid out in the company design handbook.

2.3. Security – access to schedule information must be controlled on a per-user
basis. Access to the information should not be available to any external
customers or companies.

It is best to be as specific as possible but remember the 10th commandment and be flexible. If your project doesn’t warrant this level of detail then don’t include it; or you will spend all your time writing documentation. Find a happy medium between detail and effort that suits you and your organisation’s needs.


One of the most time-consuming overheads is that of managing traceability.

Given a reasonably complex project with hundreds or perhaps thousands of stakeholder requirements how do you trace the fulfilment of a single requirement from specification, through design, development and ultimately to testing and launch?

How do your prove at test or implementation time that a requirement has been satisfied? How do you track the progress of delivery on a particular requirement during development? And how do you ensure that your design incorporates all of the particular requirements as specified in earlier phases?

The simplest method has already been outlined in the examples above. By using a common format for both the requirements specification and the technical specification it is relatively easy to track a requirement through to a design element. If the test plan is also based on the same format then the traceability can be extended to the testing phase and it can be shown in test reports — which test validates which design element and, consequently, which requirement.

However, this alone is often not enough. With large-scale projects the sheer number of requirements overwhelm this kind of formatting. It is also possible that a single requirement may be fulfilled by multiple elements in the design or that a single element in the design satisfies multiple requirements. This make tracking by simple reference number difficult.

It is possible to cross-reference requirements versus design decisions in a separate database or spreadsheet. This, however, incurs a large maintenance overhead and can be very difficult to keep in synch with the parent documents. The best solution remains an appropriate structure. While formatting and structure may not provide one-to-one traceability for every requirement, the use of an appropriate structure will minimise confusion and may eliminate the need for more complicated solutions.

At the extreme end of the scale you may wish to build or buy an integrated system to track requirements for you. There are off-the-shelf software tools available which use large databases to track individual requirements as database elements. These are then linked to similar items in specification and testing databases to provide the appropriate traceability. The benefit of a system such as this is that it can automatically produce reports which highlight problems with traceability.



End of Part 2 of A Project Management Primer

Nick Jenkins (c) 2005


About the Author:

Nick Jenkins is an IT manager with experience in software development, testing and project management. He started his working life as a software developer in Perth, Australia, where he helped author a book about educational software. He had is first management role Sydney where he helped establish the Access Testing Centre (ATC). Since then he has has worked in London, Boston and Sydney for companies like the address management specialist QAS Ltd, enterprise security firm ISS Inc. and the telco giant Singtel-Optus. Now he is living and working Prague in the Czech Republic where he is trying to learn how to speak Czech, drink slivovice (plum brandy) and ice skate.

Go to Part 1
Go to Part 2
Go to Part 4
Go to Part 4

Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.