Chapter 1

Introduction to Software Project Management

1.1 Definition Project
A project is generally defined as a program of work to bring about a beneficial change and which
has:-
 a start and an end
 a multi-disciplinary team brought together for the project
 constraints of cost, time and quality
 a scope of work that is unique and involves uncertainty

Examples of a project:-

 The development and introduction of a new services

 The development of a management information system
 The introduction of an improvement to an existing process
 Setting up a new care initiative
 The creation of a large tender or the preparation of a response to it.
 The production of a new customer newsletter, catalogue or Web site

1.2 Definition Project Management

Project management is the discipline of planning, organizing, securing, and managing resources
to achieve specific goals. A project is a temporary endeavor with a defined beginning and end
(usually time-constrained, and often constrained by funding or deliverables), undertaken to meet
unique goals and objectives, typically to bring about beneficial change or added value. The
temporary nature of projects stands in contrast with business as usual (or operations), which are
repetitive, permanent, or semi-permanent functional activities to produce products or services. In
practice, the management of these two systems is often quite different, and as such requires the
development of distinct technical skills and management strategies.

The primary challenge of project management is to achieve all of the project goals and objectives
while honoring the preconceived constraints. Typical constraints are scope, time, and budget.
The secondary—and more ambitious—challenge is to optimize the allocation and integrate the
inputs necessary to meet pre-defined objectives.

Best project management software must be intuitive and easy-to-use for project teams. Today's
project teams are scattered across the globe and they need to collaborate effectively to get
projects done faster. The real challenge is, there needs to be a project management software
which addresses all this and instantly able to setup projects from the basic to the most complex
one in a matter of few minutes without imposing much learning curve. In addition, it is aimed
towards getting things done (GTD) faster so you spend quality time at work which adds more
value for a work-life balance.

1
Business Benefits of Project Management Software
 Access all your projects anywhere and anytime using a simple web browser in a secure way
 Proper schedules, continuous uninterrupted workflow with no delays and finish projects in
time
 Keep all your key appointments, deadlines accessible from a single place
 Give a structure to how bugs are handled by defining a bug life cycle based on stages
 Collaborate with team, customers, partners - in real-time from a single place
 Create folders and organize your project documents with ease just like your personal
computer
 Escalate critical bugs and get immediate solution from experts in the team with project
forums
 Facilitate communication between people and enhance knowledge sharing among team
members

What is the Project Management Methodology?

 If a project has a beginning and an end, what is its life cycle and how is it managed?
 To be effective and workable project methodologies should be appropriate to the task and the
organisation.
 For simple projects in a small organisation, agreed milestones, a few checklists and someone
to steer the project are all that are required.
 For complex projects in a large organisation a more structured approach is needed, to set up
and approve the project, monitor and guides its progress, solve its problems, deliver the end
product (or gain) and close it down.
 In order to understand the methodology we need to look at the project life cycle. The detailed
life cycle will be dependent upon the size and type of organisation and the size and type of
the project. However, in outline they all have very similar elements.

1.3 The Project Life Cycle

A typical methodology would involve a number of stages and activities which occur at
different parts of the life cycle.

2
 The preparation stage involves the project manager and sponsor in the preparation and
approval of an outline project justification, plan and project budget.

 There is no reason why a project sponsor should not also be the project manager. A senior
manager who has a strong business reason to drive the project will have the organisational
authority and "clout" with other senior managers and will often make an excellent project
manager.

 The start up stage involves the selection and briefing of the project team and some discussion
on the roles and organisation.

 The Feasibility or Research stage will establish whether the project is feasible and establish
the risks and key success measures. Unless the organisation undertakes research or new
product development, feasibility often means ‘can this process or technology be cost
effectively applied to the organisation or department’, rather than is it generally feasible. It
may include the identification of external resources such as specialist consultants or product
and service providers who may wish to tender goods, software or services for the project.

 The work will be undertaken by the team (which may include external consultants) and co-
ordinated by the project manager. This team should consist of the key users or main
beneficiaries of the beneficial change the project is delivering (hence the term ‘project
deliverables’ or ‘products’. They may be line managers, supervisors or staff with particular
skills. They must be the best people available and never those ‘who can be spared’ because
they have difficult or awkward personalities. The object is to build a team that is better than
the sum of the individuals.

N.B. it is often the difficult people who consider and manage the detail. Their expertise and
diligence should not be ignored but they are usually happier working in a solitary way or
with likeminded individuals.

 Defining and planning the project in more detail by writing and publishing a full definition of
the project and determining a project plan. This work is undertaken by the team and co-
ordinated by the project manager. Both should be communicated widely to ensure maximum
understanding of the project’s objectives by all staff that will be affected by the project. Now
is the time to ensure their input to minimise surprises at a later stage.

 The implementation stage involves the execution of the project as agreed, whilst carefully
monitoring progress and managing changes. The team may need to be expanded at this stage
to resource all the tasks. If so, it is essential they are fully briefed and feel ‘included’ as part
of the team.

 When project management is not an integrated part of an organisation’s culture it is a very

good idea to undertake some team building events that allow the team to work together in a
competitive but non-threatening environment. As people get used to forming and dissolving
teams the need for and style of such team building events will be decided by the team.

3
 The close down stage involves the satisfactory delivery (satisfactory to the project ‘customer’
that is) of the products or services that achieve the beneficial gain. A project review should
be held to learn the lessons. These should be formally documented and published ‘warts and
all’.

1.4 Role of a Project Manager

Typically a project manager will be nominated to lead a project and will be expected to be
fully accountable for meeting its objectives. The project manager will be the leader of the
project team and will be responsible for ensuring the following are completed in a timely
way:-

 Gaining approval for the project aim and terms of reference

 Selecting and leading the team and setting individual objectives
 Ensuring a feasibility study is complete
 Ensuring that the project is planned in appropriate detail
 Allocating and monitoring the work and cost
 Motivating the team
 Reporting progress back to the organisation
 Helping the team to solve project problems
 Achieve, through the team, the goals
 Reviewing and closing down

Skills of a project manager

Very broad skills and a deal of experience are needed to manage a large project successfully.
They include business knowledge, technical skills and individual and team leadership skills.

Individual Skills
The personal skills are likely to include good presentation and persuasive skills, good written
skills but allied to goal orientation, high energy and credibility.

N.B. Having high energy does not mean you play squash five times a week but that you have
the intellectual energy and commitment to deliver the project with a positive ‘we can do it’
team approach. Good project managers know their own strengths and weaknesses and will
compensate for these in selecting the team.

Team Skills
They will appreciate the differing needs of both individuals and the project team at different
stages of the project. They will be aware of different team types.

Technical Skills
They will have technical skills in setting objectives, planning complex tasks, negotiating
resource, financial planning, contract management, monitoring skills, managing creative
thinking and problem solving, as well as their own specialist topic.

4
1.5 Tools and techniques Used

Project managers use a number of tools and techniques during a project life cycle such as:-

Verifiable objective setting

This ensures that the objectives for the project can be measured and verified to ensure that
they have been met.

Brain storming
This technique is used at all stages of the project to encourage creative thinking and solve
problems

Work Breakdown Structures

This is a technique to analyse the content of work and cost by breaking it down into its
component parts. It is produced by :-
Identifying the key elements
Breaking each element down into component parts
Continuing to breakdown until manageable work packages have been identified. These can
then be allocated to the appropriate person.

Below is a work breakdown structure for the recruitment of a new person to fill a vacant post.

Project Evaluation Review Technique (PERT)

Network analysis or PERT is used to analyse the inter-relationships between the tasks
identified by the work breakdown structure and to define the dependencies of each task.

5
Whilst laying out a PERT chart it is often possible to see that assumptions for the order of
work are not logical or could be achieved more cost effectively by re-ordering them. This is
particularly true whilst allocating resources; it may become self evident that two tasks cannot
be completed at the same time by the same person due to lack of working hours or,
conversely, that by adding an extra person to the project team several tasks can be done in
parallel thus shortening the length of the project.

Below is the PERT chart of the WBS shown above after network analysis as been applied.

Critical path analysis (CPA)

CPA is used in conjunction with PERT analysis to identify the tasks that are critical in
determining the overall duration of the project. In the example above the critical path is
shown by the tasks with heavy outline boxes.

Milestone Planning

Milestone planning is used to show the major steps that are needed to reach the goal on time.
When several tasks have been completed the milestone is reached. It is often used at senior
manager reviews.

What are Milestones? Why are they called Milestones?

Imagine you are walking along the road and you see a milestone that says 20 miles to
London so you keep walking and later you see one that says 10 miles to London. Now you
know that you are going in the right direction and you have made some progress. That is the
principle of project milestones. For example, if the project is to build a house then
completing each significant chunk of work could be considered a milestone on the road to
building the house. For example the milestones might be:-
Planning permission granted
Foundations laid
Walls constructed

6
Roof built
Fixtures, fittings and services completed
Garden landscaped
House inspected and approved
House sold

For simple projects, a milestone plan may be the only plan required.

Accrued cost and earned value analysis

These measures enable the progress of the project to be monitored in financial terms.

Gantt charts

Gantt charts (named after the inventor) or bar charts, as they are sometimes called, are used
to display and communicate the results of PERT and Critical Path analysis in a simple bar
chart format that can be readily understood by those not involved in the detail of the project.

The PERT chart above is now displayed as a Gantt chart below .

Who else would be involved and what would they do?

A number of people may be involved depending on the size of the project. They fall into a
number of groups.

The Project Sponsor

7
The project sponsor should be a senior person in the organisation who has the most to gain
from the project’s success and the most to lose if it fails.

The Steering Team

The steering team may only be one person on a small project (perhaps the project sponsor)
who meets informally with the project manager. On a large project a formal cross functional
senior team will be set up to meet regularly to review progress and provide strategic
guidance.

Functional or line managers

The line manager of each team member will want to be kept informed about the progress of
the project and be involved in setting of individual objectives.

The project customer

The project ‘customer’ should either be a member of the steering team or represented on that
team.

What are the main roles and responsibilities?

There are three key roles in the management of projects whether they are service
development projects, organisational change projects, TQM projects, or facilities projects.

Top Management
Setting the conditions and culture such that the business can select and implement
appropriate projects to support the business.
0
Middle management
Ensuring that all projects are selected, allocated, steered and closed down satisfactorily.
Ensure that projects that are not approved are not worked on.

Operational staff
To use the tools and techniques to manage projects effectively.

What about running more than one project at a time?

If an organisation is considering managing a portfolio of projects it needs to consider 5 key

areas:-

 Commitment of the senior management team to the effective use of project

management and its acceptance by staff.

 People in the organisation who have been trained in the principles and practice of
project management are required.

 Systems that provide the information needed by senior management to manage the
portfolio of projects.

8
  A methodology that is clearly understood by everyone and which every project will
follow.

 Organisational structures to select the projects that support the strategy, guide them,
prioritize them and close them down.

 Is there a hierarchy of project managers in project management?

Yes - dependent on the size of the project and the number of projects in the portfolio, an
organisation may require several people to lead different projects or significant stages of a
major project. There are generally 3 management levels but the title ‘senior’ may be added to
differentiate between experienced (or full time) project managers and those who have less
experience or are part time project managers.

Programme Manager (sometimes known as a Change Manager)

The Programme Manager is responsible to the Senior Management for the portfolio of
projects under his control. The role is a strategic one. He or she will have command of
Project Managers and Project Leaders who report for individual projects. The Programme
Manager is responsible for ensuring that the portfolio of projects deliver the beneficial
business gain intended.

Project Manager
A Project Manager is experienced in the skills and disciplines of project management, may
manage more than one project at a time and may have Project Leaders as directly reporting
staff.

Project Leader
A project leader usually manages a project stage or a small project where his or her particular
skills or expertise are a large part of the work. A Project Leader may report to a Project
Manager or to the Program Manager.

1.6 History of Project Management

As a discipline, Project Management developed from different fields of application including

construction, engineering and defense. In the United States, the forefather of project
management is Henry Gantt, called the father of planning and control techniques, who is
famously known for his use of the Gantt chart as a project management tool, for being an
associate of Frederick Winslow Taylor’s theories of scientific management, and for his study
of the work and management of Navy ship building. His work is the forerunner to many
modern project management tools including the work breakdown structure (WBS) and
resource allocation.

The 1950s marked the beginning of the modern Project Management era. Again, in the United
States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts,
and informal techniques and tools. At that time, two mathematical project scheduling models

9
were developed: (1) the “Program Evaluation and Review Technique” or PERT, developed by
Booz-Allen & Hamilton as part of the United States Navy’s (in conjunction with the Lockheed
Corporation) Polaris missile submarine program; and (2) the “Critical Path Method” (CPM)
developed in a joint venture by both DuPont Corporation and Remington Rand Corporation for
managing plant maintenance projects. These mathematical techniques quickly spread into many
private enterprises.

At the same time, technology for project cost estimating, cost management, and engineering
economics was evolving, with pioneering work by Hans Lang and others. In 1956, the American
Association of Cost Engineers (now AACE International; the Association for the Advancement
of Cost Engineering) was formed by early practitioners of project management and the
associated specialties of planning and scheduling, cost estimating, and cost/schedule control
(project control). AACE has continued its pioneering work and in 2006 released the first ever
integrated process for portfolio, program and project management (Total Cost Management
Framework).

In 1969, the Project Management Institute (PMI) was formed to serve the interests of the project
management industry. The premise of PMI is that the tools and techniques of project
management are common even among the widespread application of projects from the software
industry to the construction industry. In 1981, the PMI Board of Directors authorized the
development of what has become A Guide to the Project Management Body of Knowledge
(PMBOK Guide), containing the standards and guidelines of practice that are widely used
throughout the profession. The International Project Management Association (IPMA), founded
in Europe in 1967, has undergone a similar development and instituted the IPMA Competence
Baseline (ICB). The focus of the ICB also begins with knowledge as a foundation, and adds
considerations about relevant experience, interpersonal skills, and competence. Both
organizations are now participating in the development of an ISO project management standard.

1.7 Project Management Tips

Getting Started – Initiation

1. Develop a solid business case for your projects. Where appropriate, ensure you obtain
senior managers’ agreement before you start the project. Research points out that too
many projects are started without a firm reason or rationale. Developing a business case
will identify whether it is worth working on.

2. Ensure your project fits with the key organisational or departmental agenda or your
personal strategy. If not, why do it? Stick to priority projects.

3. Carry out risk analysis at a high level at the initiation stage. Avoid going into great detail
here – more an overview focusing on the key risks.

4. Identify at this early stage key stakeholders. Consider how much you need to consult or
involve them at the business case stage. Seek advice if necessary from senior managers

10
5. Where appropriate, involve finance people in putting the business case together. They
can be great allies in helping crunch the numbers which should give credibility to your
business case.

Defining Your Project

6. Produce a written project definition statement (sometimes called PID) and use it to
inform stakeholders – see point 13. This document is ‘your contract’ to carry out the
project and should be circulated to key stakeholders.

7. Use the project definition statement to prevent creep. Use it to prevent you going beyond
the scope of the project through its use in the review process.

8. Identify in detail what will and will not be included in the project scope. Avoid wasting
time by working on those areas which should not be included – identify these in the PID.

9. Identify who fulfils which roles in your project. Document them on the PID. Include a
paragraph to show what each person does.

10. Identify who has responsibility for what in the project e.g. project communications is the
responsibility of AD. This helps reduce doubt early in the life of the project.

11. Think ‘Team Selection’ – give some thought to who should be in your team. Analyse
whether they have the skills required to enable them to carry out their role? If not, ensure
they receive the right training. Check they are available for the period of the project.
NOTE: this includes any contactors you may need to use

12. Form a group of Project Managers. The Project Manager role can sometimes be very
lonely! Give support to each other by forming a group of Project Managers.

13. Identify who the stakeholders are for your project – those affected and ‘impacted’ by the
project. This should be an in- depth analysis which needs updating regularly.

14. Recognise early in the life of the project what is driving the project. Is it a drive to
improve quality, reduce costs or hit a particular deadline? You can only have 1.
Discuss with the sponsor what is driving the project and ensure you stick to this
throughout the project. Keep “the driver” in mind especially when you monitor and
review.

15. Hold a kick off meeting (Start up Workshop) with key stakeholders, sponsor, project
manager project team. Use the meeting to help develop the PID (see Tip 6). Identify
risks and generally plan the project. If appropriate hold new meetings at the start of a
new stage.

11
16. Ensure you review the project during the Defining Your Project Stage – involve your
sponsor or senior manager in this process. Remember to check progress against the
business case.

Delivery Planning

17. Create a work breakdown structure (WBS) for the project. A WBS is a key element you
will need to develop your plan. It lists out all of the activities you will need to undertake
to deliver the project. Post it notes can be a great help in developing your WBS.

18. Group tasks under different headings once you have a list. This will enable you to
identify the chunks of work that need to be delivered, as well as put together the Gantt
chart and milestone chart.

19. Identify dependencies (or predecessors) of all activities. This will let you put together the
Gantt and milestone charts. Ensure you write them down otherwise you are trying to
carry potentially hundreds of options in your head.

20. Estimate how long each activity will take. Be aware that research points out we are
notoriously bad at estimating. You estimate a task will take 3 days. Identify how
confident you are that you can deliver in 3 days by using %
e.g. I’m only 40% certain I can deliver in 3 days. You should aim for 80%. If you do
not believe you can achieve 80% then re-calculate

21. Identify the critical path for the project. The critical path identifies those activities which
have to be completed by the due date in order to complete the project on time.

22. Communicate, communicate, communicate! Delivering a project effectively means you

need to spend time communicating with a wide range of individuals. Build a
communication plan and review it regularly and include it in your Gantt chart.

23. Are you involved in a major change project? If you are, think through the implications of
this on key stakeholders and how you may need to influence and communicate with
them.

24. Conduct Risk Assessment – carry out a full risk analysis and document it in a risk
register. Regularly review each risk to ensure you are managing them, rather than them
managing you. Appoint a person to manage each risk.

25. Develop a Gantt chart and use it to monitor progress against the plan and to involve key
stakeholders in the communications process.

12
26. Draw up a milestone plan. These are stages in the project. You can use the milestone
dates to check the project is where it should be. Review whether activities have been
delivered against the milestone dates and take a look forward at what needs to be
achieved to deliver the next milestone.

Project Delivery – Monitoring and Reviewing Your Project (Project Governance)

27. Have a clear project management monitoring and reviewing process – agreed by senior
managers - the project sponsor and the project Board, if you have one.

28. Ensure your organisation’s corporate governance structure and your project management
monitoring and control structure are compatible. If you do not know whether this is the
case then seek senior management involvement.

29. Be aware early in the project what will be monitored, how they will be monitored and the
frequency.

30. Keep accurate records of your project not only for audit purposes but to ensure you have
documents which enable you to monitor changes.

31. Use a Planned v. Actual form. It is easy to create – it allows you to monitor how you are
progressing with specific tasks – time and money. Link these forms into milestone
reviews.

32. Identify with your sponsor the type of control that is needed – loose or tight or a variation
of these, e.g. tight at the start, loose in the middle, tight at the end. Ensure the system you
develop reflects the type of control intended.

33. Agree a system for project changes – have an agreed system for monitoring and
approving changes. Use change control forms and obtain formal sign off (agreement) by
the sponsor, before action a change. Look for the impact of the change on the project
scope as well as the “key driver” - quality, and cost and time.

34. Appoint someone to be responsible for project quality especially in larger projects.
Review quality formally with the client at agreed milestone dates.

35. Make certain you have agreed who can sanction changes in the absence of your sponsor.
If you haven’t agreed this, what will you do in their absence?

36. Set a time limit for project meetings to review progress. Have an agenda with times
against each item and summarise after each item at the end of the meeting.

37. Produce action points against each item on the agenda and circulate within 24 hours of
the meeting. Use these action points to help in the creation of your next agenda.

13
38. Review the items on the critical path checking they are on schedule. Review risks,
review yours stakeholders and your communication plans and whether you are still on
track to deliver on time, to budget and to the required quality standard.

39. Set a tolerance figure and monitor e.g. a tolerance figure of ±5% means as long as you
are within the 5% limit you do not have to formally report. If exceed the 5% limit (cost
or time) then you need to report this to the agreed person – probably your sponsor

40. Report progress against an end of a stage – are you on schedule? Time, cost or quality?
Ensure that if something is off schedule the person responsible for delivering it suggests
ways to bring it back on time, within budget or to hit the right quality standard.

41. Develop an issues log to record items that may be causing concern. Review at your
project meetings.

42. See whether you are still delivering the original project benefits when reviewing your
project. If not, consider re-scoping or if appropriate abandoning the project. Do not be
afraid of abandoning a project. Better to abandon now rather than waste valuable time,
money, and resources working on something no longer required. If you close a project
early – hold a project review meeting to identify learning.

43. Produce one-page reports highlighting key issues. Agree the areas to include with the
Sponsor before writing a report.

44. Use a series of templates to support the monitoring process, e.g. milestone reporting,
change control, log, planned v. actual.

45. Apply traffic lights to illustrate how you are progressing – red, amber and green. Use
these in conjunction with milestone reports.

46. Engender honest reporting against specific deliverables, milestones, or a critical path
activity. If you do not have honest reporting imagine the consequences.

Closedown and Review

47. Agree well in advance a date to hold a post project review meeting. Put this onto the
Gantt chart.

48. Invite key stakeholders, sponsor, and project team to the post project review. If the date is
in their diary well in advance it should make it easier for them to attend

49. Focus your meeting on learning – identifying what you can use on the next project.
Share the learning with others in the organisation.

14
50. Check whether you have delivered the original project objectives and benefits and not
gone out of scope.

51. Make sure that you have delivered against budget, quality requirements and the end
deadline.

52. Understand how well you managed risks and your key stakeholders. Use questionnaires
to obtain feedback.

53. Prepare a list of unfinished items. Identify who will complete these after the project and
circulate to any stakeholders.

54. Hand over the project formally to another group (it is now their day job) - if appropriate.
You may need to build this into the project plan and involve them early in the plan and at
different stages throughout the project.

55. Write an end of project report and circulate. Identify in the report key learning points.

56. Close the project formally. Inform others you have done this and who is now responsible
for dealing with day to day issues.

57. Celebrate success with your team! Recognise achievement, there is nothing more
motivating.

1.8 Requirements & Specifications

Defining requirements to establish specifications is the first step in the development of an

embedded system. However, in many situations, not enough care is taken in establishing correct
requirements up front. This causes problems when ambiguities in requirements surface later in
the life cycle, and more time and money is spent in fixing these ambiguities. Therefore, it is
necessary that requirements are established in a systematic way to ensure their accuracy and
completeness, but this is not always an easy task. This difficulty in establishing good
requirements often makes it more of an art than a science. The difficulty arises from the fact that
establishing requirements is a tough abstraction problem and often the implementation gets
mixed with the requirements. In addition, it requires people with both communication and
technical skills. As requirements are often weak about what a system should not do, this poses
potential problems in the development of dependable systems, where these requirements are
necessary to ensure that the system does not enter an undefined state. The development of
dependable embedded systems requires even more complicated requirements as the embedded
system not only interacts with the software but also with the outside world. Therefore, the
importance of establishing good requirements is even greater in embedded systems design.

Requirements and specifications are very important components in the development of any
embedded system. Requirements analysis is the first step in the system design process, where a
15
user's requirements should be clarified and documented to generate the corresponding
specifications. While it is a common tendency for designers to be anxious about starting the
design and implementation, discussing requirements with the customer is vital in the
construction of safety-critical systems. For activities in this first stage has significant impact on
the downstream results in the system life cycle. For example, errors developed during the
requirements and specifications stage may lead to errors in the design stage. When this error is
discovered, the engineers must revisit the requirements and specifications to fix the problem.
This leads not only to more time wasted but also the possibility of other requirements and
specifications errors. Many accidents are traced to requirements flaws, incomplete
implementation of specifications, or wrong assumptions about the requirements. While these
problems may be acceptable in non-safety-critical systems, safety-critical systems cannot tolerate
errors due to requirements and specifications. Therefore, it is necessary that the requirements are
specified correctly to generate clear and accurate specifications.

There is a distinct difference between requirements and specifications. A requirement is a

condition needed by a user to solve a problem or achieve an objective. A specification is a
document that specifies, in a complete, precise, verifiable manner, the requirements, design,
behavior, or other characteristics of a system, and often, the procedures for determining whether
these provisions have been satisfied. For example, a requirement for a car could be that the
maximum speed to be at least 120mph. The specification for this requirement would include
technical information about specific design aspects. Another term that is commonly seen in
books and papers is requirements specification which is a document that specifies the
requirements for a system or component. It includes functional requirements, performance
requirements, interface requirements, design requirements, and development standards.

Establishing Correct Requirements

The first step toward developing accurate and complete specifications is to establish correct
requirements. As easy as these sounds, establishing correct requirements is extremely difficult
and is more of an art than a science. There are different steps one can take toward establishing
correct requirements. Although some of the suggestions sound fairly obvious, actually putting
them into practice may not be as easy as it sounds. The first step is to negotiate a common
understanding. There is a quote by John von Neumann that states "There's no sense being exact
about something if you don't even know what you're talking about." Communication between the
designer and customer is vital. There is no point in trying to establish exact specifications if the
designers and customers cannot even agree on what the requirements are.

Problem stems from ambiguities in stating requirements. For example, say the requirement states
that we want to create a means that would transport a group of people from Boston to
Washington D.C. Possible interpretations of this requirement includes building a bus, train, or
airplane, among other possibilities. Although each of these transportation devices satisfies the
requirement, they are certainly very different. Ambiguous requirements can be caused by
missing requirements, ambiguous words, or introduced elements. The above requirement does
not state how fast the people should be transported from Boston to Washington D.C. Taking an
airplane would certainly be faster than riding a bus or train. These are also missing requirements.

16
"a group of people" in the above requirement is an example of ambiguous words. What exactly
does "group" imply? A group can consist of 5 people, 100 people, 1000 people, etc. The
requirement states to "create a means" and not "design a transportation device". This is an
example of introduced elements where an incorrect meaning slipped into the discussion. It is
important to eliminate or at least reduce ambiguities as early as possible because the cost of them
increases as we progress in the development life cycle.

Often the problem one has in establishing correct requirements is how to get started. One of the
most important things in getting started is to ask questions. Context-free questions are high-level
questions that are posed early in a project to obtain information about global properties of the
design problem and potential solutions. Examples of context-free questions include who is the
client?, what is the reason for solving this problem?, what environment is this product likely to
encounter?, and what is the trade-off between time and value?. These questions force sides,
designer and customer, to look at the higher issues. Also, since these questions are appropriate
for any project, they can be prepared in advance. Another important point is to get the right
people involved. There is no point in discussing requirements if the appropriate people are not
involved in the discussion. Related to getting the right people involved is making meetings work.
Having effective meetings is not as easy as it sounds. However, since they play a central role in
establishing requirements it is essential to know how to make meetings work. There are
important points to keep in mind when creating effective meetings, which include creating a
culture of safety for all participants, keeping the meeting to an appropriate size, and other points.

Exploring the possibilities is another important step toward generating correct requirements.
Ideas are essential in establishing correct requirements, so it is important that people can get
together and generate ideas. Every project will also encounter conflicts. Conflicts can occur from
personality clashes, people that cannot get along, intergroup prejudice such as those between
technical people and marketing people, and level differences. It is important that a facilitator is
present to help resolve conflicts.

In establishing requirements, it is important to specifically establish the functions, attributes,

constraints, preferences, and expectations of the product. Usually in the process of gaining
information, functions are the first ones to be defined. Functions describe what the product is
going to accomplish. It is also important to determine the attributes of a product. Attributes are
characteristics desired by the client, and while 2 products can have similar functions, they can
have completely different attributes. After all the attributes have been clarified and attached to
functions, we must determine the constraints on each of the attributes. Preferences, which is a
desirable but optional condition placed on an attribute, can also be defined in addition to its
constraints. Finally, we must determine what the client's expectations are. This will largely
determine the success of the product.

Testing is the final step on the road to establishing correct requirements. There are several testing
methods used, as listed below.
 Ambiguity poll - Used to estimate the ambiguity in a requirement. This involves asking
questions such as how fast?, how big?, how expensive?, and then determining if there is
ambiguity between the high and low values.

17
  Technical review - A testing tool for indicating the progress of the requirements work. It
can be formal or informal and generally only deals with technical issues. Technical
reviews are necessary because it is not possible to produce error-free requirements and
usually it is difficult for the producers to see their own mistakes.
 User satisfaction test - A test used on a regular basis to determine if a customer will be
satisfied with a product.
 Black box test cases - Constructed primarily to test the completeness, accuracy, clarity,
and conciseness of the requirements.
 Existing products - Useful in determining the desirable and undesirable characteristics of
a new product.
At some point it is necessary to end the requirements process as the fear of ending can lead to an
endless cycle. This does not mean that it is impossible to revisit the requirements at a later point
in the development life cycle if necessary. However, it is important to end the process when all
the necessary requirements have been determined, otherwise you will never proceed to the
design cycle.

Establishing good requirements requires people with both technical and communication skills.
Technical skills are required as the embedded system will be highly complex and may require
knowledge from different engineering disciplines such as electrical engineering and mechanical
engineering. Communication skills are necessary as there is a lot of exchange of information
between the customer and the designer. Without either of these two skills, the requirements will
be unclear or inaccurate.

It is essential that requirements in safety critical embedded systems are clear, accurate, and
complete. The problem with requirements is that they are often weak about what a system should
not do. In a dependable system, it is just as important to specify what a system is not suppose to
do as to specify what a system is suppose to do. These systems have an even greater urgency that
the requirements are complete because they will only be dependable if we know exactly what a
system will do in a certain state and the actions that it should not perform. Requirements with no
ambiguities will also make the system more dependable. Extra requirements will usually be
required in developing a dependable embedded system. For example, in developing a dependable
system for non-computer-literate people, extra requirements should be specified to make the
system safe even in exceptional or abusive situations.

Requirements and Specification's Role in System Design

Systems exist everywhere in the universe we live in. The universe can be considered a system,
and so can an atom. A system is very loosely defined and can be considered as any of the
following definitions.
 A combination of elements forming a complex or unitary whole (i.e. river system or
transportation system)
 A set of correlated members (i.e. system of currency)
 An ordered and comprehensive assemblage of facts, principles, or doctrines in a
particular field of knowledge (i.e. system of philosophy)
 A coordinated body of methods, a complex scheme, or a plan of procedure (i.e. system of
organization and management)
 Any regular or special method of plan of procedure (i.e. a system of marking)

18
 The important characteristic of a system is that there is unity, functional relationship, and useful
purpose. Systems engineering is not a technical specialty but is a process used in the evolution of
systems from the point when a need is identified through production and construction to
deployment of the system for consumer use. Systems engineering requires knowledge from
different engineering disciplines such as aeronautical engineering, civil engineering, and
electrical engineering. The development of embedded systems also requires the knowledge of
different engineering disciplines and can follow the techniques used for systems engineering.
Therefore, it is appropriate that the steps used in establishing system requirements also be
applicable to requirements for embedded systems. The conceptual system design is the first stage
in the systems design life cycle and an example of the systems definition requirements process is
shown in Figure 1. Each individual box will be explained below.

Figure 1: Example of system requirements definition process [Blanchard90]

In establishing system requirements, the first step is to define a need. This need is based on a
want or desire. Usually, an individual or organization identifies a need for an item or function
and then a new or modified system is developed to fulfill the requirement. After a need is
defined, feasibility studies should be conducted to evaluate various technical approaches that can
be taken. The system operational requirements should also be defined. This includes the
definition of system operating characteristics, maintenance support concept for the system, and
identification of specific design criteria. In particular, the system operational requirements
should include the following elements.

 Mission definition - Identification of the primary operating mission of the system in

addition to alternative and secondary missions.
 Performance and physical parameters - Definition of the operating characteristics or
functions of the system.
 Use requirements - Anticipation of the use of the system.
 Operational deployment or distribution - Identification of transportation and mobility
requirements. Includes quantity of equipment, personnel, etc. and geographical location.
 Operational life cycle - Anticipation of the time that the system will be in operational use.

19
  Effectiveness factors - Numbers specified for system requirements. Includes cost-system
effectiveness, mean time between maintenance (MTBM), failure rate, maintenance
downtime, etc.
 Environment - Definition of the environment in which the system is expected to operate.
 Basically, the system operational requirements define how the system will be used in the
field by the customer.

Usually, in defining system requirements, the tendency is to cover areas that are related to
performance as opposed to areas that are related to support. However, this means that emphasis
is only placed on part of the system and not the whole system. It is essential to take into
consideration the entire system when defining system requirements. The system maintenance
concept basically describes the overall support environment that the product is supposed to exist
in.

After the system operational requirements and system maintenance concept are defined, the
preliminary system analysis is performed to determine which approach for system development
should be adopted. The following process is usually applied.

1. Define the problem - The first step always begin with clarifying the objectives, defining the
concerned issues, and limiting the problem so that it can be effectively studied.
2. Identify feasible alternatives - All the alternatives should be considered to make sure that the
best approach is chosen.
3. Select the evaluation criteria - The criteria for the evaluation process can vary considerably, so
the appropriate ones must be chosen.
4. Applying modeling techniques - A model or series of models should be used.
5. Generate input data - The requirements for appropriate input data should be specified.
6. Manipulate the model - After data is collected and inputted, the model may be used. Analysis
after using the model will lead to recommendation for some kind of action.
After the preliminary system analysis, advanced system planning will be done. Early system
planning takes place from the identification of a need through the conceptual design phase. The
results from these planning will be defined as either technical requirements included in the
specifications or management requirements included in a program management plan. The
documents associated with these requirements are shown in Figure 2. The system specification
includes information from the operational requirements, maintenance concept, and feasibility
analysis. The System Engineering Management Plan(SEMP) contains three sections. The
technical program planning and control part describes the program tasks that have to be planned
and developed to meet system engineering objectives such as work breakdown structure,
organization, risk management, etc. The system engineering process part describes how the
system engineering process applies to program requirements. Finally, the engineering specialty
integration part describes the major system-level requirements in the engineering specialty areas
such as reliability, maintainability, quality assurance, etc.

20
Figure 2: Program documentation

Finally, the conceptual design review is also performed during the conceptual design stage. It
usually occurs early in the system engineering development life cycle after the operational
requirements and the maintenance concept have been defined.

Requirements Traceability
It is very important to verify that the requirements are correctly implemented in the design. This
is done with requirements traceability which is usually referred to as "the ability to follow the
life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its
development and specification, to its subsequent deployment and use, and through periods of on-
going refinement and iteration in any of these phases.)" Requirements traceability captures the
relationships between the requirements, specifications, and design. Standards for systems
development such as the one from the U. S. Department of Defense (standard 2167A) require
that requirements traceability be used. Although requirements traceability has been around for
more than 2 decades, there has been no consensus as to what kind of information should be used
as part of a traceability scheme. The problem is that the definition of traceability differs when
taken from different points of view of the system.(i.e. the view of the system is different for
customer, project manager, test engineer, etc.) Each organization has a different purpose and
methodology for requirements tracing. While it is not the purpose of this paper to dwell into a
long discussion about requirements traceability, a short example of the methodology used at one
organization will be given.

The projects typically involved at Abbott Laboratories Diagnostics Division are real-time,
embedded, in vitro diagnostic instruments approaching 200,000 lines of code. They have found
that traceability aids project managers in verification, cost reduction, accountability and change

21
management. Traceability helps in verifying that software requirements are satisfied in the
design process and that they are tested for during the verification process. Traceability allows the
allocation of product requirements early in the development cycle thereby reducing costs of
correcting defects (due to untraceable components) in the integration and system test phase.
Providing quantitative traceability analyses also allows for accountability in making sure that
project milestones are approved, deliverables are verified, and customers are satisfied. The
documentation from traceability also keeps information organized during changes in staff or
management.

A specific in vitro diagnostic instrument contained approximately 175,000 lines of source code
and approximately 1,600 software requirements that needed to be traced. While the division also
has an automated traceability system (ATS) that allowed them to automate many of the tasks, it
was the process and not the tool that led to their success. The main purpose of the traceability
program is to identify links and determine that the links are complete and accurate. The
traceability analysis consists of 4 aspects: forward requirements analysis, reverse requirements
trace, forward test analysis, and reverse test trace. These steps are used to trace each software
requirement through its design elements and test traces. The ATS can be used to design
documentation matrices and test matrices that are used to perform the different analyses required.
The ATS is also able to give feedback about the design components that are not yet implemented
during the life cycle. In the test phase, the ATS gives input to what requirements are covered by
the test cases.

Requirements Standards
There are many requirements and specification standards. They are mostly military standards as
opposed to "commercial" standards. In addition, most of the standards are in the systems
engineering area, and in particular deals with the software aspects. A good reference to many of
these standards is Standards, Guidelines, and Examples on System and Software Requirements
Engineering from the IEEE Computer Society Press. This book is a compilation of international
requirements standards and U. S. military standards. There is also a section on requirements
analysis methodologies and examples. Listed below are several relevant standards, but the list is
in no means exhaustive.

Available tools, techniques, and metrics

The key tool for requirements traceability is the RDD-100 from Ascent Logic. In the past
decade, RDD-100 has been mainly used in the aerospace, defense, and telecommunications
industry. Today, its use is spreading to commercial industries engaging in systems engineering
and information systems re-engineering projects. Among its many capabilities, RDD-100 can
define requirements rigorously. In particular, the RDD-100 uses its
Element/Relationship/Attribute repository to capture and trace complicated requirements. Each
requirement is stored as a separate element, and graphical hierarchies show how the individual
pieces of data relate to each other and trace back to their sources.

There also exist requirements simulation tools. Foresight, produced by Nu Thena Systems,
allows designers to capture system requirements and designs into graphical executable system
models. These models can be analyzed and simulated to ensure requirements correctness. The
SES workbench is a system-level simulation software tool that focuses on behavioral and

22
performance modeling. Rational Rose is a visual modeling tool that among other features, allows
UML modeling. The trend is towards executable requirements and simulations.

The Unified Modeling Language (UML) is an object-oriented modeling language for the
specification of complex systems. UML represents a large effort from a number of
methodologists to construct a common means of describing complex systems using object
orientation. It is a specification language and not a development process so there are no details
given on the features and how and when you link them together during systems development.
UML is a relatively new language, and is still going through debate about the feasibility of using
them in embedded systems. The main concerns about using an object oriented language for real-
time embedded systems are about the speed and size of the application. Some points in support
of object-oriented programming for embedded systems are that objects are efficient, developers
can write larger systems with fewer defects in less time using OO methods instead of structured
methods, and OO can be implemented in any language, including assembly language. Other
people have also stated arguments against using UML for embedded systems. In particular,
restrictions in architectural modeling were cited as one shortfall. For example, there are no
predefined node stereotypes to help improve standardization and the lack of these predefined
stereotypes means there is no capability to capture information in depth to fully describe the
operational properties of the system. Another shortfall deals with deficiencies in concurrency
modeling and schedulability. However, UML is still relatively new and only time will tell if it is
effective in the specification and development of embedded systems.

It would also be very helpful to have a technique that can assist in a structured development of
correct and accurate requirements. In particular, Quality Function Deployment (QFD) is a
method for the structured product planning and development that enables a development team to
specify clearly the customer's wants and needs, and then evaluate each proposed product or
service capability systematically in terms of its impact on meeting those needs. QFD is based on
matrices that show the relationships between, for example, a customer need and a feature of the
system. Figure 3 shows an example of a matrix that gives the relationship for each row and
column. For example, say the rows define customer wants in a car. Let’s say A is the car looks
cool and B is the car never breaks. The columns can be specific features of the car. Let’s say 1 is
good gas mileage and b is aerodynamic styling. Each box represents the relationship between a
customer want and a feature of the car. A car with good gas mileage is not related to the car
looking cool, so there is no relation. However, a car with aerodynamic styling would look cool
so there is a strong relation. Similarly, a car with that never breaks has a possible relation with
good gas relation but not much relation with aerodynamic styling.

23
Figure 3: Example of matrix used in QFD

1.9 Organizational Control Techniques

Control techniques provide managers with the type and amount of information they need to
measure and monitor performance. The information from various controls must be tailored to a
specific management level, department, unit, or operation.

To ensure complete and consistent information, organizations often use standardized documents
such as financial, status, and project reports. Each area within an organization, however, uses its
own specific control techniques, described in the following sections.

Financial controls
After the organization has strategies in place to reach its goals, funds are set aside for the
necessary resources and labor. As money is spent, statements are updated to reflect how much
was spent, how it was spent, and what it obtained. Managers use these financial statements, such
as an income statement or balance sheet, to monitor the progress of programs and plans.
Financial statements provide management with information to monitor financial resources and
activities. The income statement shows the results of the organization's operations over a period
of time, such as revenues, expenses, and profit or loss. The balance sheet shows what the
organization is worth (assets) at a single point in time, and the extent to which those assets were
financed through debt (liabilities) or owner's investment (equity).

Financial audits, or formal investigations, are regularly conducted to ensure that financial
management practices follow generally accepted procedures, policies, laws, and ethical
guidelines. Audits may be conducted internally or externally. Financial ratio analysis examines
the relationship between specific figures on the financial statements and helps explain the
significance of those figures:

 Liquidity ratios measure an organization's ability to generate cash.

 Profitability ratios measure an organization's ability to generate profits.
 Debt ratios measure an organization's ability to pay its debts.

24
  Activity ratios measure an organization's efficiency in operations and use of assets.

In addition, financial responsibility centers require managers to account for a unit's progress
toward financial goals within the scope of their influences. A manager's goals and
responsibilities may focus on unit profits, costs, revenues, or investments.

Budget controls
A budget depicts how much an organization expects to spend (expenses) and earn (revenues)
over a time period. Amounts are categorized according to the type of business activity or
account, such as telephone costs or sales of catalogs. Budgets not only help managers plan their
finances, but also help them keep track of their overall spending.

A budget, in reality, is both a planning tool and a control mechanism. Budget development
processes vary among organizations according to who does the budgeting and how the financial
resources are allocated. Some budget development methods are as follows:

Top-down budgeting. Managers prepare the budget and send it to subordinates.

Bottom-up budgeting. Figures come from the lower levels and are adjusted and coordinated as
they move up the hierarchy.

Zero-based budgeting. Managers develop each new budget by justifying the projected allocation
against its contribution to departmental or organizational goals.

Flexible budgeting. Any budget exercise can incorporate flexible budgets, which set “meet or
beat” standards that can be compared to expenditures.

Marketing controls
Marketing controls help monitor progress toward goals for customer satisfaction with products
and services, prices, and delivery. The following are examples of controls used to evaluate an
organization's marketing functions:

Market research gathers data to assess customer needs—information critical to an organization's

success. Ongoing market research reflects how well an organization is meeting customers'
expectations and helps anticipate customer needs. It also helps identify competitors.

Test marketing is small-scale product marketing to assess customer acceptance. Using surveys
and focus groups test marketing goes beyond identifying general requirements and looks at what
(or who) actually influences buying decisions.

Marketing statistics measure performance by compiling data and analyzing results. In most
cases, competency with a computer spreadsheet program is all a manager needs. Managers look
at marketing ratios, which measure profitability, activity, and market shares, as well as sales
quotas, which measure progress toward sales goals and assist with inventory controls.

25
Unfortunately, scheduling a regular evaluation of an organization's marketing program is easier
to recommend than to execute. Usually, only a crisis, such as increased competition or a sales
drop, forces a company to take a closer look at its marketing program. However, more regular
evaluations help minimize the number of marketing problems.

Human resource controls

Human resource controls help managers regulate the quality of newly hired personnel, as well as
monitor current employees' developments and daily performances.

On a daily basis, managers can go a long way in helping to control workers' behaviors in
organizations. They can help direct workers' performances toward goals by making sure those
goals are clearly set and understood. Managers can also institute policies and procedures to help
guide workers' actions. Finally, they can consider past experiences when developing future
strategies, objectives, policies, and procedures.

Common control types include performance appraisals, disciplinary programs, observations, and
training and development assessments. Because the quality of a firm's personnel, to a large
degree, determines the firm's overall effectiveness, controlling this area is very crucial.

Computers and information controls

Almost all organizations have confidential and sensitive information that they don't want to
become general knowledge. Controlling access to computer databases is the key to this area.

Increasingly, computers are being used to collect and store information for control purposes.
Many organizations privately monitor each employee's computer usage to measure employee
performance, among other things. Some people question the appropriateness of computer
monitoring. Managers must carefully weigh the benefits against the costs—both human and
financial—before investing in and implementing computerized control techniques.

Although computers and information systems provide enormous benefits, such as improved
productivity and information management, organizations should remember the following
limitations of the use of information technology:

Performance limitations. Although management information systems have the potential to

increase overall performance, replacing long-time organizational employees with information
systems technology may result in the loss of expert knowledge that these individuals hold.
Additionally, computerized information systems are expensive and difficult to develop. After the
system has been purchased, coordinating it—possibly with existing equipment—may be more
difficult than expected. Consequently, a company may cut corners or install the system carelessly
to the detriment of the system's performance and utility. And like other sophisticated electronic
equipment, information systems do not work all the time, resulting in costly downtime.

Behavioral limitations. Information technology allows managers to access more information than
ever before. But too much information can overwhelm employees, cause stress, and even slow
decision making. Thus, managing the quality and amount of information available to avoid
information overload is important.

26
1.10 Project management triangle

The Project Management Triangle (called also Triple Constraint) is a model of the constraints of
project management. It is often used to illustrate that project management success is measured by
the project team's ability to manage the project, so that the expected results are produced while
managing time and cost.

Like any human undertaking, projects need to be performed and delivered under certain
constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost". These
are also referred to as the "Project Management Triangle," (also known as the "Iron Triangle")
where each side represents a constraint. One side of the triangle cannot be changed without
affecting the others. A further refinement of the constraints separates product "quality" or
"performance" from scope, and turns quality into a fourth constraint.

Dr. Martin Barnes created the 'project management triangle' in the 1970s. 45 years later, Barnes
is still active in project management serving as President of APM. He is also a founding member
of the Association, an honorary fellow and past chairman Quoted from.

The time constraint refers to the amount of time available to complete a project. The cost
constraint refers to the budgeted amount available for the project. The scope constraint refers to
what must be done to produce the project's end result. These three constraints are often
competing constraints: increased scope typically means increased time and increased cost, a tight
time constraint could mean increased costs and reduced scope, and a tight budget could mean
increased time and reduced scope.

The discipline of Project Management is about providing the tools and techniques that enable the
project team (not just the project manager) to organize their work to meet these constraints.

Another approach to Project Management is to consider the three constraints as finance, time and
human resources. If you need to finish a job in a shorter time, you can throw more people at the
problem, which in turn will raise the cost of the project, unless by doing this task quicker we will
reduce costs elsewhere in the project by an equal amount.

27
Time
For analytical purposes, the time required to produce a deliverable is estimated using several
techniques. One method is to identify tasks needed to produce the deliverables documented in a
work breakdown structure or WBS. The work effort for each task is estimated and those
estimates are rolled up into the final deliverable estimate.

The tasks are also prioritized, dependencies between tasks are identified, and this information is
documented in a project schedule. The dependencies between the tasks can affect the length of
the overall project (dependency constrained), as can the availability of resources (resource
constrained). Time is different from all other resources and cost categories.

According to PMBOK the Project Time Management processes include :

Activity Definition
Activity Sequencing
Activity Resource Estimating
Activity Duration Estimating
Schedule Development
Schedule Control

Activity Definition (detail)

1a. Activity Definition Inputs

Enterprise environmental factors, Organizational process assets, Project Scope statement, Work
Breakdown Structure, WBS Dictionary, Project Management Plan
1b. Activity Definition Tools
Decomposition, Activity Templates, Rolling Wave Planning, Expert Judgment Collection,
Planning Components
1c. Activity Definition Outputs
Activity list, Activity scope attributes, Milestones list, Change Requests

Activity Sequencing (detail)

2a. Activity Sequencing Inputs

Project Scope Statement, Activity List, Activity Attributes, Milestones List, Approved change
requests
2b. Activity Sequencing Tools
Precedence Diagramming Method (PDM), Arrow Diagramming Method (ADM), Schedule
Network templates, Dependency degeneration, Applying leads and lags
2c. Activity Sequencing Outputs
Project Schedule Network diagrams, Activity List Updates, Activity Attributes Updates,
Request Changes

Activity Resource Estimating (detail) :

3a. Activity Resource Estimating Inputs

28
 Enterprise Environmental factoring, Organizational process assets, Activity list, Activity
attributes, Resources Availability, Project Management Plan
3b. Activity Resource Estimating Tools
Expert Judgment Collections, Alternative Analysis, Publishing estimating data, Project
management software implementation, Bottom up estimating
3c. Activity Resource Estimating Outputs
Activity resource requirements, Activity attributes, Resource breakdown structure, Resource
calendars Request change updates.

Activity Duration Estimating (detail):

4a. Activity Duration Estimating Inputs

Enterprise environmental factors, organization process assets, Project scope statement, activity
list, activity attributes, activity resource requirements, resource calendars, project management
plan, risk register, activity cost estimates
4b. Activity Duration Estimating Tools
Expert judgment collection, analogous estimating, parametric estimating, three point estimating,
reserve analysis
4c. Activity Duration Estimating Outputs
Activity duration estimates, activity attribute updates and estimates

Schedule Development (detail):

5a. Schedule Development Inputs

Organizational process assets, Project scope Statement, Activity list, Activity attributes, project
Schedule Network diagrams, Activity resource requirements, Resource calendars, Activity
duration estimates, project management plan, risk register
5b. Schedule Development Tools
Schedule Network Analysis, Critical path method, schedule compression, what if scenario
analysis, resources leveling, critical chain method, project management software , applying
calendars, adjusting leads and lags, schedule model
5c. Schedule Development Outputs
Project schedule, Schedule model data, schedule baseline, resource requirements update, activity
attributes, project calendar updates, request changes, project management plan updates, schedule
management plan updates

Schedule Control (detail):

6a. Schedule Control Inputs

Schedule management plan, schedule baseline, performance reports, approved change requests
6b. Schedule Control Tools
Progressive elaboration reporting, schedule change control system, performance measurement,
project management software, variance, analysis, schedule comparison bar charts
6c. Schedule Control Outputs

Cost

29
To develop an approximation of a project cost depends on several variables including: resources,
work packages such as labor rates and mitigating or controlling influencing factors that create
cost variances tools used in cost are, risk management, cost contingency), cost escalation, and
indirect costs . But beyond this basic accounting approach to fixed and variable costs, the
economic cost that must be considered includes worker skill and productivity which is calculated
using various project cost estimate tools. This is important when companies hire temporary or
contract employees or outsource work.

Cost Process Areas

Cost Estimating is an approximation of the cost of all resources needed to complete activities.
Cost budgeting aggregating the estimated costs of resources, work packages and activities to
establish a cost baseline.
Cost Control - factors that create cost fluctuation and variance can be influenced and controlled
using various cost management tools.

Project Management Cost Estimating Tools

Schedule model data updates, schedule baseline. performance measurement, requested changes,
recommended corrective actions, organizational process assets, activity list updates, activity
attribute updates, project management plan updates

Due to the complex nature of the Process Group called 'Time' the unique project management
credential PMI-SP (PMI Scheduling Professional) was created.

Analogous Estimating
Using the cost of similar project to determine the cost of the current project
Determining Resource Cost rates
The cost of goods and labor by unit gathered through estimates or estimation.
Bottom up estimating
Using the lowest level of work package detail and summarizing the cost associated with it. Then
rolling it up to a higher level aimed and calculating the entire cost of the project.
Parametric Estimating
Measuring the statistical relationship between historical data and other variable or flow.
Vendor Bid Analysis
taking the average of several bids given by vendors for the project.
Reserve Analysis
Aggregate the cost of each activity on the network path then add a contingency or reserve to the
end result of the analysis by a factor determined by the project manager.
Cost of Quality Analysis
Estimating the cost at the highest quality for each activity.

Project managers often use project management software to calculate the cost variances for a
project.

Scope

30
Requirements specified to achieve the end result. The overall definition of what the project is
supposed to accomplish, and a specific description of what the end result should be or
accomplish. A major component of scope is the quality of the final product. The amount of time
put into individual tasks determines the overall quality of the project. Some tasks may require a
given amount of time to complete adequately, but given more time could be completed
exceptionally. Over the course of a large project, quality can have a significant impact on time
and cost (or vice versa).

Together, these three constraints have given rise to the phrase "On Time, On Spec, On Budget."
In this case, the term "scope" is substituted with "specification."

Evolution of the Project Constraint Model

Traditionally the Project Constraint Model recognized three key constraints; "Cost", "Time" and
"Scope". These constraints construct a triangle with geometric proportions illustrating the strong
interdependent relationship between these factors. If there is a requirement to shift any one of
these factors the at least one of the other factors must also be manipulated.

With mainstream acceptance of the Triangle Model, "Cost" and "Time" appear to be represented
consistently. "Scope" however is often used interchangeably given the context of the triangle's
illustration or the perception of the respective project. Scope / Goal / Product / Deliverable /
Quality are all relatively similar and generic variation examples of this, while the above
suggestion of 'People Resources' offers a more specialized interpretation.

This widespread use of variations implies a level of ambiguity carried by the nuance of the third
constraint term and of course a level of value in the flexibility of the Triangle Model. This
ambiguity allows blurred focus between a project's output and project's process, with the
example terms above having potentially different impetus in the two contexts. Both "Cost" and
"Time" represent the top level project's inputs.

The ‘Project Diamond’ model engenders this blurred focus through the inclusion of "Scope" and
"Quality" separately as the ‘third’ constraint. While there is merit in the addition of "Quality" as
a key constraining factor, acknowledging the increasing maturity of project management, this
model still lacks clarity between output and process. The Diamond Model does not capture the
analogy of the strong interrelation between points of the triangles however.

More recently the Project Management Book of Knowledge (PMBOK 4.0) offered an evolved
model based on the triple constraint with 6 factors to be monitored and managed. This is
illustrated as a 6 pointed Star that maintains the strength of the triangle analogy (two overlaid
triangles), while at the same time represents the separation and relationship between project
inputs/outputs factors on one triangle and the project processes factors on the other.

31
The Project Management Diamond Model

The Project Management Star per PMBOK

32
Interpretation of Triangle Model

Interpretation of Star Model

PMBOK 4.0 6 Point Star variables:

Triangle 1

33
  Scope
 Cost
 Time

Triangle 2
 Risk
 Quality
 Resources

When considering the ambiguity of the third constraint and the suggestions of the "Project
Diamond"; it is possible to consider instead the Goal or Product of the project as the third
constraint, being made up of the sub factors "Scope" and "Quality". In terms of a project's output
both "Scope" and "Quality" can be adjusted resulting in an overall manipulation of the
Goal/Product. This interpretation includes the four key factors in the original triangle
inputs/outputs form. This can even be incorporated into the PMBOK Star illustrating that
"Quality" in particular may be monitored separately in terms of project outputs and process.
Further to this suggestion, the use of term "Goal" may best represent change initiative outputs,
while Product may best represent more tangible outputs.

Every Project plan is a triangle

It doesn't matter what industry you're in, how experienced you are, how "different" your project
is, or what version of project management methodology your organization uses. At every
project's core is the trio of time, money, and scope.
These are the factors you juggle every day to keep your Project plan on track.
 What is the project triangle?
 Where's the stuck side of the triangle?
 How do I optimize to meet my schedule?
 How do I optimize to meet my budget?
 How do I optimize to meet my scope requirements?
 What does quality have to do with the project triangle?

What is the project triangle?

If time, money, or what your project accomplished were unlimited, you wouldn't need to do
project management. Unfortunately, most projects have a specific time limit, budget, and scope.

It is this combination of elements (time, money, and scope) that we refer to as the project
triangle. (These competing elements are sometimes referred to as the triple constraints of a
project.) Understanding the project triangle will allow you to make better choices when you need
to make tradeoffs.

34
If you adjust any one side of the triangle, the other two sides are affected.

For example, if you decide to adjust the project plan to:

 Bring in the scheduled finish date, you might end up with increased costs
and a decreased scope.
 Meet the project budget, the result might be a longer schedule and a decreased scope.
 Increase scope, your project might take more time and cost more money in the form of
resources, such as workers.

Changes to your plan can affect the triangle in various ways, depending on your specific
circumstances and the nature of your project. For example, in some instances, shortening your
schedule might increase costs. In other instances, it might actually decrease costs.

In terms of the project triangle, resources are considered a cost item. So as you adjust resources
to accommodate more or less work or to reflect their availability, your costs go up or down
correspondingly. These costs are based on resource pay rates.

You also may notice that as you adjust resources, your schedule changes. For example, if you
have a number of resources over allocations and you level the project, the schedule might now
include split tasks and delays that extend the finish date.

Where's the stuck side of the triangle?

Did you say "stuck side"? That's right. In most projects, at least one side of the triangle is stuck,
meaning you're stuck, because you can't change it. On some projects, it's the budget. No matter
what, you won't get more money for the project. On others, it's the schedule—the dates can't
change. Or it's the scope—there will be no change in deliverables.

The trick is in finding the "stuck" or fixed sides of your project's triangle. That tells you what
you can change and where to adjust if there's a problem. Phrasing the problem as a statement can
help you clarify which side of the triangle is in trouble.

Knowing which side of your triangle can't be changed will help you know where to adjust. So
when you begin optimizing:
 First, decide which of the three elements is fixed. This is typically the element most
important to the success of your project (finishing on time, on budget, or with the agreed-
upon scope).
 Then, determine which side your current problem occurs on. Once you've done that,
you'll know what elements you have to work with to get your project back on track.
35
If the problem side and the fixed side are the same, you have the remaining two sides of the
triangle to work with. For example, if your project has to finish on time and your problem is that
it's taking too long, you can adjust resources or adjust scope to get the project back on track.

If the problem side is different than the fixed side, you'll want to optimize by adjusting the
remaining side. For example, if your project has to finish on time and it's grown in scope, you
only have the cost side to play with by, for instance, by adding resources.

Know that when you adjust one side of the triangle of time, money, and scope, the other two
sides are likely to be affected. They can be affected positively or negatively, depending on the
nature of your project.

How to optimize to meet the schedule

After analyzing your schedule, you might find it does not meet the project deadline. There are
several ways you can adjust the length of your schedule. The methods you choose depend on the
limitations imposed on the project as a whole, such as budget, resource availability, scope, and
the flexibility of the tasks.

The most efficient way to shorten the schedule is to change the tasks that lie on the critical path.
The critical path is a series of dependent tasks whose last task finishes at the project end date. If
any of the tasks in this series move, the project end date also moves. Modifying tasks that are not
on the critical path may not affect the schedule. You can:
 Shorten the durations of tasks (usually a reflection of reduced scope or increased/more
efficient resources).
 Overlap tasks so that they can be worked on simultaneously.
 Remove tasks to meet the finish date (usually a reflection of reduced scope).
 Assign additional resources.
 Decrease the amount of work assigned (usually a reflection of reduced scope or more
efficient resources).

As you adjust the schedule, your costs might increase, resources might become over allocated,
and your scope might change. For example, if you shorten durations of tasks on the critical path,
the project will probably finish sooner, but the scope of those tasks and possibly the entire
project might be reduced. Or if you assign additional resources to critical path tasks so that they
can be finished more quickly, you might find that these resources are now over allocated, and
you need to pay overtime, increasing your costs.

How to optimize to meet the budget?

You might find that the Project plan you have built exceeds your budget. Project costs are
affected primarily by resources assigned to the tasks in the project: the rate-based cost and the
fixed costs of people, equipment, and materials.

36
Therefore, to reduce costs, you can cut project scope so that there are fewer tasks or shorter
durations for tasks that need resources.

If you don't want to cut scope, you can adjust resources and make sure that your settings for
rates, fees, and overtime are correct. You can verify that the resources assigned are the best for
the job. You might be able to replace a more expensive resource with a less expensive one, and
use the more expensive resource where it is most cost-effective.

As you adjust the plan to meet your budget, your finish date might be extended, or the scope
might decrease. For example, if you remove overtime from tasks that had over allocated
resources assigned, you might find the schedule lengthened to the point where the finish date is a
month later. Or if you've cut scope to meet the budget, you might find that the finish date is
actually scheduled to occur sooner.

How to optimize to meet the scope requirements?

There are two aspects of scope to consider—product scope and project scope:
Product scope describes the final deliverables of the project, usually in great detail. Examples of
product scope include product specifications or blueprints. As a project manager, you may not
have much control over product scope.

Project scope includes all of the project work done to produce the deliverables described by the
product scope. As a project manager, you normally have at least some control over project scope.
For example, you may be able to skip code reviews for some deliverables.

Typically, you adjust scope when you find a problem with meeting the finish date or the budget.
You can cut scope to bring in the finish date or cut costs. You can also increase scope if you find
you have additional time or an increased budget available.

Changing scope usually involves changing the number or the duration of tasks. Scope is closely
related to quality. When you increase scope, you have the opportunity to build in higher quality.
When you decrease scope, you might need to lower standards of acceptable quality.

If you reduce scope, your costs might decrease and your finish date might occur sooner. If you
add scope, your costs might increase and your finish date might be later. For example, if you cut
a series of tasks that were considered optional, you may not need as many resources, resulting in
cost savings. Or if you're increasing scope by adding more time to a series of tasks, you might
find that changing scope affects the scheduling of critical path tasks, and the finish date is now
two weeks later.

What does quality have to do with the project triangle?

37
Quality is at the center of the project triangle. Quality affects every side of the triangle, and any
changes you make to any side of the triangle are likely to affect quality. Quality is not a factor of
the triangle; it is a result of what you do with time, money, and scope.

For example, if you find you have additional time in your schedule, you might be able to
increase scope by adding tasks and duration. With this extra time and scope, you can build a
higher level of quality into the project and its deliverables.

Or if you need to cut costs to meet your budget, you might have to decrease scope by cutting
tasks or reducing task durations. With decreased scope, there might be fewer opportunities to
achieve a certain level of quality, so a lower quality results from the need to cut costs.

38