Project Management - Software Development Methodology

Download as pdf or txt
Download as pdf or txt
You are on page 1of 24

View metadata, citation and similar papers at core.ac.

uk brought to you by CORE


provided by Research Papers in Economics

146 Zvonimir Vukovi}

PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT


METHODOLOGY
Dipl. ing. Zvonimir Vukovi}
Siemens d.d.

Abstract
This article talks about project management in a software development area.
The emphasis is given to the process of software development and the main respon-
sibilities of the project manager. Furthermore, some aspects of different manage-
ment topics that can be found in almost all projects nowadays are also described. To
have a successful project one needs to have a team of persons who will participate
in the project according to their professional expertise. The teams and sub-teams are
defined and their roles are described.

1. Introduction
Today’s world market is a very sophisticated business area. A huge number of
competitors in most of industrial areas are confronted with requests to deliver
“state-of-the-art” products in less time, with less money and higher quality. And
those who pick any two mentioned variables and let the third one get “as good as
possible” do not survive long. Only those who are able to really manage all three
variables will be successful enough to withstand all the challenges and remain acti-
ve in the market. Of course, it is very hard to achieve remarkable results in all rele-
vant areas. If we concentrate on the area of software development, one of the que-
stions one might ask himself is: “How to manage my software development process
to achieve better results than my competitors do?” There is no straightforward
answer to this question, but there is definitively a way one should follow to get
there. Along this way one very important, if not most important, thing is called
”Project Management” (PM)
Today, the increased significance of project management is apparent. Projects
are being used as temporary organizations with the goal of performing any kind of
large-scaled processes in the project-oriented organizations. Also, project manage-
ment has established itself as a new discipline and project manager has become a
new profession.

2. Project Management
2.1. What is a Project?
The subject of project management is a project.
“Projects are complex, mostly new, risky and important undertakings for the
organization undertaking the project. They are goal-determined tasks, since the
objectives for the deliverables, the deadlines, the resources and the costs are agreed
between the project owner and the project team” (“pm-baseline”, p. 10).
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 147

Project is not any repetitive continuous process; it’s a one-time event.


Each project is initiated by the need of an organization to deliver new products
and solutions to the market in order to produce profit, knowledge or something else
of the organization’s interest. The economic consequences of an investment through
a project can be analyzed in a “Business Case Analysis” and “Feasibility Study”.
The objective of a Business Case is not only to analyze immediate project costs and
benefits, but also the resulting follow-up costs and benefits. The objective of a
Feasibility Study is to give us a hint in respect to the possible risks of not being able
to achieve defined project objectives for whatsoever reason.
Each project has it’s own main objective which is defined at the very begin-
ning. It is the task of the project management process to ensure that project main
objective is achieved.
There are some common things that most of the projects share among them-
selves, e.g.:
- Specific start and end date
- Time schedule, budget and quality constraints
- Specific efforts to achieve the result and specific set of risks

2.2. What is Project Management?


Let’s define the term Project Management. A huge variety of definitions for
this term are available. I will present here a few definitions that seem to be most
adequate for the purpose of this document:
“Project management is a business process of the project-oriented organiza-
tion” (“pm-baseline”, p. 11)
“Project management is a carefully planned and organized effort to accomplish
a specific (and usually) one-time effort, for example, construct a building or imple-
ment a new computer system. Project management includes developing a project plan,
which includes defining project goals and objectives, specifying tasks or how goals
will be achieved, what resources are need, and associating budgets and timelines for
completion. It also includes implementing the project plan, along with careful controls
to stay on the "critical path", that is, to ensure the plan is being managed according to
plan. Project management usually follows major phases (with various titles for these
phases), including feasibility study, project planning, implementation, evaluation and
support/maintenance” (www.managementhelp.org).
“Project management is the application of knowledge, skills, tools and techni-
ques to a broad range of activities to meet the requirements of the particular proj-
ect. Project management knowledge and practices are best described in terms of
their component processes. These processes can be placed into five process groups
(initiating, planning, executing, controlling and closing) and nine knowledge areas
(project integration management, project scope management, project time manage-
148 Zvonimir Vukovi}

ment, project cost management, project quality management, project human resour-
ce management, project communications management, project risk management
and project procurement management).” (www.ask.org).
So we can see that Project Management is not a trivial thing, but a set of acti-
vities that are focused on achieving desired results in appropriate way for the com-
pany, the clients and the society. There are three very important limits that we can
find in almost all the projects: time, money and quality. Two of them we may not
exceed - time and money and the third one – quality – must be at least as required
by the customers if not even better. Sometimes it seems that these three things
determine almost everything we do within the project – and the praxis will confirm
this in many every-day situations. But only such project management process that
learns on the experiences from the past, that considers future projects and opportu-
nities and that regards the main resources, i.e. people as most valuable thing for the
involved organization can be successful for a long time. From the personal expe-
rience I consider very important to emphasize that project management must also
be rational and objective.
As already mentioned in the given definitions for the term Project
Management, we can see that this process is actually a process of managing a num-
ber of other, mutually dependant sub-processes each having its own objective, but
contributing to the main project objective. Let’s tell a few words about most impor-
tant of them.

2.2.1. Integration Management


Integration management is “a subset of project management that includes the
processes required to ensure that the various elements of the project are properly
coordinated”, (www.englertandassociates.com/glossary/)
In other words, each project involves a lot of resources that must be coordina-
ted. Be it people who may be placed all over the world and speak different langua-
ges, or technologies that must be brought into cooperation, or similar.

2.2.2. Scope Management


Scope management is “a subset of project management that includes the pro-
cesses required to ensure that the project includes all of the work required, and only
the work required, to complete the project successfully”, (www.englertandassocia-
tes.com/glossary/)
Scope of the work necessary to fulfil main project objective must be defined
to the best possible approximation in the early stages of project development. This
is important for many later considerations such as adequate resource planning or
time scheduling. If project related activities loose the focus, this will certainly pro-
duce higher costs and resource consumption, delivery dates will get shifted and the
whole project will be endangered.
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 149

2.2.3. Time Management


Time management is “a subset of project management that includes the pro-
cesses required to ensure timely completion of the project. It consists of activity def-
inition, activity sequencing, activity duration estimating, schedule development,
and schedule control.”, (www.englertandassociates.com/glossary/).
Since time is one of the most important things that must be obeyed during proj-
ect development, it will involve a lot of planning and reviewing on monthly, weekly
or even daily basis.
We shall define here the term “Milestone”. Milestones represent significant
points in the project development and are generally associated with important
results. They are defined using time and appropriate deliverables. In another words
milestones define end of certain project development phase. We shall see later that
some of the most important signals of successful or unsuccessful project develop-
ment are the milestones, i.e. if they are obeyed or not.

2.2.4. Cost Management


Cost management is “a subset of project management that includes the pro-
cesses required to ensure that the project is completed within the approved budget.
It consists of resource planning, cost estimating, cost budgeting, and cost control.”,
(www.englertandassociates.com/glossary/)
Of course, the money is one of the most important things one should take care
about. If we manage to deliver products with fewer budgets, then we shall definiti-
vely be very competitive on the market. It’s not all about being cheap at the end. It’s
also about managing costs during development process. A project manager must
have access to all relevant data and means how to track current expenses and to esti-
mate future expenses. Thereby, project manager can influence final, overall costs. It
is quite usual, although rarely desired, that initial budget has to be re-planned due
to unexpected things in the course of development.

2.2.5. Quality Management


Quality management is “a subset of project management that includes the acti-
vities required to ensure that the project will satisfy the needs for which it was
undertaken. It consists of quality planning, quality assurance and quality control. It
includes configuration management“, (www.eurocontrol.int/eatmp/glossar/teryms/
/terms-16.htm)
One, also very important thing to take care about is Quality Management.
Today, there are a lot of different quality certificates one company can obtain to
prove that its products are good quality products (e.g. ISO, CMM1). Such certifica-

1 CMM (Capability Maturity Model) – certificate of a certain level of quality in software


development which was originally developed in USA by NASA. Today it’s in use in some com-
panies all over the world.
150 Zvonimir Vukovi}

tes are periodically, mostly on yearly basis, tested and renewed or withdrawn. But,
not everything is in a certificate. Each company must find it’s own best way how to
manage quality in the course of product development. For quality assurance, there
are usually specialists – quality assurance responsible persons - who cooperate with
project managers during product development and thereby contribute in the areas of
their expertise. A common thing to say is “four eyes see better than two”. The main
task of a quality assurance responsible person is to assure that product development
is done according to the official, and perhaps certified, method that the company
uses. Also, the quality of the product is being tested in the course of development.
A huge variety of tools and methods are used for this. Some of them are:
- Design reviews
- Internal reviews of documentation and code - reviews done by the develop-
ment team
- External reviews of documentation and code - reviews done by some other
teams or by the customer
- Usage of configuration management tools to manage software versions
- Regression tests - automated tests of all specified features (useful to prove
that latest changes or updates did not influence previously developed functionality)
- System tests – overall tests performed by the company that has developed a
product. Such tests include not only tests of specified functionality but also per-
formance tests, high-load tests, integration tests, etc.

Figure 1: Quality/Costs diagram


PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 151

Finally, the quality has its price. Following is a diagram showing how much it
costs to achieve certain degree of quality.
So, we can see that it’s not worth spending enormous amounts of money to
reduce the expenses for error corrections. There is an optimum that must be detec-
ted, achieved and maintained.

2.2.6. Human Resource Management


Human resource management is “the project management task that ensures
that adequate resources are allocated to the endeavour.”, (www.donald-firesmith.
com/Glossary/GlossaryR.html)
As we all know, in spite of all the technology that we have today, people are
still the most valuable and unavoidable resource. First of all, a project manager must
be a person that is as such accepted by the team. Second, a project manager must be
familiar with the team members, i.e. must know strong sides and weaknesses of all
involved persons in order to adequately distribute tasks among them. Finally, a proj-
ect manager must cooperate with team members, and must be willing to accept
other opinions presented by team members. If those preconditions are met, it is most
likely that development tasks (usually called “Working Packages”) will be distribu-
ted most adequately. Further, a project manager must plan the order and time frame
for each individual activity according to development phases. That means that
amount of necessary human resources may vary in the course of development.
Usually, in the early stages and final stages less people are involved in development,
and in the middle stages the pressure gets very high involving most of the people.
So, the teams are usually not static, meaning that some team members may in some
stages be engaged on some other projects. The project manager must, also, be aware
of what is going on within other projects in the company, not only to be able to
reserve enough people for different stages in the project, but also to be able to use
the knowledge and experience that people gather in other projects. Of course, peo-
ple are not machines, so a project manager must be aware of planned and unplan-
ned absences, holidays and similar.

2.2.7. Risk Management


Risk management is “the systematic process of identifying, analysing, and
responding to project risk. It includes maximizing the probability and consequences
of positive events and minimizing the probability and consequences of events
adverse to achieving project objectives. It includes the processes of risk manage-
ment planning, risk identification, qualitative risk analysis, quantitative risk analy-
sis, risk response planning, and risk monitoring and control.”
(www.fieldoperative.com/Tools/Glossary/Glossary%20p.htm)
All activities within a project, as well as the final outcome of the project, invol-
ve certain degree of risk. This is something that cannot be avoided regardless of the
level of quality or experience the organization has. Risks are everywhere, and only
152 Zvonimir Vukovi}

possible strategy is the one that systematically takes care of risks from the very
beginning. That is, risks must be identified, planned and analysed as early as possi-
ble within a document called “Risk Plan” or similar. For each identified risk, a proj-
ect manager together with the team must recognize necessary measures how to
either avoid the risk or minimize it. That is, the identified risks must be evaluated,
prioritised, minimized and followed. The risks can be identified in the later phases
of the project as well meaning that the risk plan must be updated. Higher manage-
ment levels must be acquainted with all identified risks in all stages of product deve-
lopment. Sometimes risk analysis leads to the “no go” decision for the project, or to
stopping of already ongoing projects. Gathered experience from earlier projects is
of enormous value for risk analysis and management. Some project development
methodologies consider so called “Kick Off Meeting“ and “Lessons Learned
Workshop”. The former is held at the very beginning of the project, the latter at the
very end of the project. Both occasions have a common item in agenda – risk man-
agement. In the “Kick Off” meeting risks are usually being identified by all team
members on a risk management session using a variety of methods (e.g. brainstor-
ming, or experience). In the “Lessons Learned” workshop all involved team mem-
bers analyse how the risks have been planned, identified and taken care of with
respect for the future projects and better risk management.
In some recent terminologies, the word risk is replaced with the word challen-
ge. All highly project oriented, methodology based organisations with high degree
of self confidence and market strength tend to see the risk as an opportunity to find
solution for it and thereby get more advantage over others.

2.2.8. Claim Management


In the world of software development, we understand the term Claim
Management mainly as a way in which to cope with changes in requirements that
are being received or identified at some later phases in the project. Usually, the
client finds out some new and interesting services that can be delivered to end-users.
These ideas are then being translated into so-called Change Request in a form of a
technical document describing the desired features or functionality. It is up to the
project manager to decide what is the best way to deal with such change requests.
The options are either to postpone the implementation of the change request until
previously agreed product is finished or to do it immediately. The decision depends
mainly on complexity of necessary changes.

2.2.9. Configuration Management (CM)


Configuration management is “the process of identifying and defining
Configuration Items in a system, recording and reporting the status of Configuration
Items and Requests For Change, and verifying the completeness and correctness of
Configuration Items.”(http://www.itil.co.uk)
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 153

In another words, configuration management is a system that makes it possi-


ble to have a centralized storage place for all relevant project specific data (e.g.
documents, source code, test tools, …). It is possible, and of course widely used, to
keep track of all versions of the stored data throughout the whole project develop-
ment process and to make a centralized backup as well. All this makes it a “must
have” tool for every serious project. Usually, there is a separate team of experts (CM
team) who maintain such system for number of projects. Sometimes CM team con-
tributes to the project by creating CM specific documentation.

2.2.10. Information Management


Information Management is “a method used to organize information to avoid
information overload and to keep information in a format that is efficient to retrie-
ve whenever needed. Filing systems, cognitive maps, manuals, and electronic data-
bases are examples of devices that can prove useful in information management. A
network of consultants is an additional way to ensure that necessary information
will be readily available.”, (www.iime.org/glossary.htm)
Today we have Internet as a global network available for everyone and every-
where. From the organizational point of view, there is a similar thing called Intranet.
Intranet is “a private network inside a company or organization, which uses softwa-
re like that used on the Internet, but is for internal use only, and is not accessible to
the public. Companies use Intranets to manage projects, provide employee infor-
mation, distribute data and information, etc”, (www.getnetwise.org/glossary.php)
Intranet, as the definition already mentions, is the ideal resource for keeping
and publishing all relevant project specific data. Usually, though not necessary,
development methodologies include a point in early stages where it is the task of the
project manager to organize an Intranet Web Site dedicated for the project purpos-
es. Of course, such Web Sites have a common “look and feel”, are easy to use and
employees are used to them. Besides that, there is also e-mail as a way for publis-
hing information. E-mail is used very often and in distributed environments it is
sometimes the most important way of communication. So, the combination of
Intranet and e-mail makes it possible to manage information flow very efficiently
and with low resource consumption. Having such technology available, the projects
are being managed much easier.

2.3. A Key Person - Project Manager


A Project Manager is a person that is responsible for the project and, therefo-
re, the one who leads the project towards a successful or, sometimes, unsuccessful
finish. A project manager must have a set of competences that make him/her appro-
priate person for such a duty. These competences cannot be learned in the school or
in a workshop. One must develop himself/herself through active engagement on
specific tasks within one or more projects. Visiting and participating in dedicated
154 Zvonimir Vukovi}

seminars and workshops can help gathering further experience and knowledge.
Therefore becoming a project manager is not something that people should be afraid
of, it’s just something that doesn’t occur over night.
A project manager, besides leading the project, communicates with other rela-
ted instances involved in and around the project. There is a role of interface that the
project manager must play. Most common and important relations are those with
project sponsors and clients. Project manager is directly responsible to the project
sponsor since the sponsor is the one who orders a project to be executed. Project
sponsor (usually higher management levels of the organization) usually defines
some specific boundaries (e.g. budget, time, quality) and monitors them closely.
Clients are those who usually specify the requirements and negotiate technical
details of realization that are of high importance to them. When we talk about soft-
ware development, a common situation is that the client orders some extensions of
already existing systems, or wants some new systems that are compatible to other
existing systems. In any case, very usual things are change requests during deve-
lopment or after finishing the original project. A project manager is the one that
must coordinate all negotiations with the client.
So, how to pick the right person for this job? There are some guidelines to help
in such situations. The project sponsor or other higher management instances could
use the following picture to think about necessary competences.

Figure 2: Project Manager Competences


PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 155

Specific Technical Competences were earlier one of the main things that were
necessary for the person to become a project manager. Today, this is not any more
the only criterion, sometimes even not relevant at all.
Project Management Competences together with appropriate knowledge of
methodology and experience are becoming more and more important nowadays.
Social and Communication Skills are necessary for leading all the people
involved in a project, for being an interface towards external parties and for under-
standing and using team-oriented approach.
Now, to choose from a number of available and adequate persons following
approach could be used:

Figure 3: Process of choosing the right Project Manager

Selection Process is a decision making process done by higher level manage-


ment by means of examining, qualifying and evaluating all relevant aspects of a par-
ticular project.

Specific Requirements Profile describes necessary or specific qualifications of


the potential Project Manager for the particular project.
Qualification Profile describes all relevant qualifications and competences of
a potential Project Manager. This information is gathered from a point of view of
higher-level management and a person itself, agreed upon and published
156 Zvonimir Vukovi}

In practise, many companies have an automated process (computer aided,


using variety of available software solutions) to help gathering all relevant data and
choosing the right project manager.

2.3.1. Project Manager Tasks and Duties


Everyone, confronted with project manager duties would like to know at least
the answer to the following question: “What do I have to do now?”
Well, like in many other things, there is no straightforward answer to this que-
stion. But, some hints do exist. Following table presents some key objectives2 with
respect to the client and higher-level management that each project manager has to
be aware of:

Table1: Project Manager Objectives

2 Partially taken from - Jason Charvat: ” Project Management Methodologies-Selecting,


Implementing, and Supporting Methodologies and Processes for Projects”
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 157

In addition, there are some common responsibilities that we can identify here3:
- Obtaining approval for the project to proceed.
- Determining the project scope and its feasibility to the overall business.
- Ensuring the necessary project resources are identified and allocated.
- Planning the project to the relevant detail it requires.
- Ensuring that the project methodology and associated processes are adhered
to.
- Monitoring the project in terms of cost, quality, and schedule.
- Identifying and monitoring project issues and risks.
- Providing updated reports and summaries to the higher management and
clients.
- Providing leadership to the project team.
In more details, we can pinpoint here some experience-based suggestions or
rules that are useful to the project manager4:
Project success criterion must be well defined. It is not enough just to meet the
scheduled dates of delivery. Nowadays, it gets more and more important to achieve
global market success by means of either technological achievements, new and
interesting services, or similar.
Release criteria must be identified well. Early in the project it must be known
what criterion will be used to determine if product is ready to be released or not.
This can be a number of critical defects that are not solved, list of available and not
available features regarding given requirements, performance results, etc.
Commitments must be negotiated. A good project manager will not make com-
mitments that are not realistic despite of the applied pressure. Good-faith negotia-
tions (also known as win-win negotiations) must take place between higher man-
agement, customers and project manager to find acceptable solutions for all sides.
A plan must be written and available before any development starts. By wri-
ting plans, one must do thinking, discussing, brainstorming, experience gathering
and similar activities. All this gets very useful at later stages in the project by avoi-
ding problems, being more productive, having better quality and better mood in the
team
Create and use working packages. It is very useful to break large development
tasks into smaller pieces keeping their integrity. Distribute such tasks appropriately
among project team members and keep track of progress at regular intervals.
Plan to do enhancements as a result of quality control activities. Usually, if not
always, there will be necessary to undertake corrective actions based on performed
testing activities.

3 Partially taken from - Jason Charvat: ” Project Management Methodologies-Selecting,


Implementing, and Supporting Methodologies and Processes for Projects”.
158 Zvonimir Vukovi}

Manage the risks. Risks must be identified and controlled. The time spent on
this is not thrown away. Use brainstorming, experience and other methods to iden-
tify risks, evaluate them and avoid them as much as possible. But, one should be
aware of the fact that it is not possible to avoid all the risks. Therefore, detect when
it is not worth spending further efforts on risk analysis and calculate certain buffer.
Do your estimations feature based not calendar based. All identified develop-
ment efforts should be estimated based on necessary time for realization (a meas-
urement unit is usually called “Man-Hours”, MA). Most of all it is experience, but
also a variety of developed estimation methods that can help here. Only then, trans-
late the results into calendar days.
Don’t over schedule your team members. Every project manager must be
aware of the fact that there is a certain amount of overhead in every activity. It is
either switching among activities or preparation for certain activities or temporary
resource congestion or similar that needs time to be solved. Plan your people with
80% of their time.
Calculate training time, vacation time, sickness, etc. Use experience or avera-
ge values for vacations, sickness and training activities. Ask your team members to
give you some forecasts. Build this data into your plans
Note your estimation data. It can be very useful to document all assumptions,
approaches, identified key issues and other relevant discussion topics for later
usage. This can help in later estimation adjustments and it can improve overall esti-
mation process.
Record actual progress and estimated efforts. By comparing actually achieved
results to the estimated ones, a project manager can improve estimation process
significantly.
Recognize tasks as completed only when they are 100% complete. The way
how to recognize tasks as completed must be transparent and understood by ever-
yone. As long as there are any open issues, even minor ones, the tasks should not be
treated as finished
Track project status openly and honestly. All team members must feel free and
comfortable when discussing project status issues. Reports on this matter must be
accurate and available. An experienced project manager will not let the misleading
optimism, that sometimes exists, to influence his/hers objectiveness. Organize cele-
brations at important stages and at the end of a successful project.

3. Project Management Methodology


According to Jason Charvat5 a methodology is a set of guidelines or principles
that can be tailored to a specific situation. In a project environment, these guideli-

4 Partially taken from – Karl E. Wiegers: “Secrets of Successful Project Managemen”.


5 Jason Charvat: ” Project Management Methodologies—Selecting, Implementing, and
Supporting Methodologies and Processes for Projects”.
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 159

nes might be a list of things to do. A methodology could also be a specific approach,
templates, forms and even checklists used over the project life cycle.
Today, there is a huge number of methodologies in use. Some companies use
methodologies that cover all aspects of the business, from pre-sales activities to
operational support. Some other companies use methodologies only during design
and development. There is no universal methodology available; everybody uses its
own methodology. Even similar methodologies get adapted to the specifics of the
company, i.e. many project managers have realized that “methodologies from the
book” must be modified and tailored to suit their own project needs.
Also, there are different methodologies within the same company for big and
small projects (those that engage many or few people, last longer or shorter, etc.).
A company that uses certain methodology should make it transparent to the
customers as much as possible. Furthermore, some companies offer their customers
to choose from a set of methodologies the one that will be used for the project rea-
lization. This makes it possible for the customer to track the progress and to know
exactly what intermediate results and deliverables should be available at certain
points in time.
Many companies get their methodologies certified. Certificates are usually
tested at regular time frames by external certification authorities to prove that the
methodology is really being used and that it addresses all relevant and important
areas (e.g. environmental protection is an important issue even for the software
development companies)
Finally, a methodology must not be too complex or inappropriate in any way
to be seen as a burden for the people who use it. It must be light, understandable and
goal oriented, it must be seen as a tool for achieving success. It should make the life
easier.

4. Software Development Methodology


Further in this document an example of a software development methodology
will be presented. The aim is to have a methodology that is easy to implement and
follow, that is goal oriented and that can easily be adapted to large-scale as well as
small-scale projects.

4.1. Main Phases


Following picture presents main phases of such methodology
4.2. Milestones
It is necessary to define some milestones. Milestones are “interim objectives,
points of arrival in terms of time for purposes of progress management”6. In other
words, milestones are used to define necessary deliverables at appropriate points in

6 www.maxwideman.com
160 Zvonimir Vukovi}

Figure 4: Project Phases

Table 2: Milestones

time. Mostly, when milestones are met certain phases are finished. Nevertheless,
milestones can be defined within the phases if necessary. Let’s define following
milestones:

4.3. Resources
Resources, be it people, money, hardware or similar, are necessary throughout
the whole project development. Based on experience and specifics of each project
it is possible to foresee the trend of amount of necessary resources in regards to each
project phase. Following picture presents some usual cases.
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 161

Figure 5: Time – Resources Diagram


So we can see that necessary amount of people involved in a project gets the
maximum in the phase of implementation. Early phases as well as later phases
involve less human resources.
Hardware, on the other hand, is a resource that grows towards final phases.
This is characteristic for software development since final phases involve tests
where it is actually attempted to simulate real environments.
Of course, there can be more or less differences to what is presented here.
Furthermore other resources, such as money, must be planned in advance according
to inputs that are available at the beginning of the project.
Every project manager must know the trends of resource consumption and
according to the experience and available inputs (there are also software tools avai-
lable for such purposes) must plan exact amounts of necessary resources for the
whole project. During project development there will usually be necessary to do
certain corrections, but the goal of planning is to make later corrections as minor as
possible.

4.4. Project Team


4.4.1. Teamwork
“A team is a small number of people with complementary skills who are com-
mitted to a common purpose, performance goals, and approach for which they hold
themselves mutually accountable“7

7 Jon Katzenbach and Douglas Smith, The Wisdom of Teams


162 Zvonimir Vukovi}

Teamwork is more and more becoming a core factor of modern organizations.


Mainly projects ask for integration of different disciplines and procedures across the
organizations. Successful teams have a clear goal understood and accepted by all
members. In addition there is an atmosphere of open and useful discussion among
the members, conflicts get solved easily and openly. Everyone within such team
understands their roles and tasks and carry out their share of load. A success-orien-
ted motivation is developed.
All this and many other things make it necessary to develop and maintain good
quality teams of people that are available for project tasks. If a team is available,
project can be done, otherwise key resources are not available.
One very important characteristic of a project manager is to be recognized by
the team as a team leader.

4.4.2. Sub Teams


Project team consists of people who work on the project. As shown previously,
the number of involved persons is not constant and it depends on the actual phase
of the project. Nevertheless, it is possible to identify certain groups (sub-teams)
within project team that share common tasks (or duties) and in general act more clo-
sely together. Following picture gives an overview of the groups of people within a
project team:

Figure 6: Project Team – Sub-Teams

Project Manager is responsible for the whole project


Quality Assurance Manager is responsible for achieving necessary level of
quality by ensuring that project tasks are being conducted according to the official
development method. Since all involved persons in the project should know the
methodology well, QM has mainly controlling function. QM is the often “right
hand” for the project manager and his/hers representative. For QM it is not unusual
to be focused on few projects in parallel.
PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 163

Development Team is responsible for product implementation (coding in our


case) according to the requirements and design. Development team is present in cer-
tain amount in almost all phases of the project. During analysis and design it is quite
usual that development team members are involved or at least consulted. Phase of
implementation belongs entirely to the development team. Integration is a phase
where development team is integrating all developed components in a functional
entity. During test phase, development team is engaged in error corrections. Also,
development team is responsible for internal, highly technical documentation such
as interface specifications, developer manuals and similar
Analysis and Design Team consists of senior developers, analysis specialists
and design specialists. This team is mostly engaged in early phases of the project.
Later in the project analysis and design team members are consulted in case that
special circumstances occur or change requests appear.
Documentation Team is responsible for creation of all necessary documents
that must be delivered together with the final product. Sometimes it is hard to
distinguish what documents should be created by documentation team and what
should be created by development team. It is the task of PM and QM to make appro-
priate work split in such situation.
Test Team is responsible for creation of test specifications, execution of all
necessary test cases and, in case of detected errors, reporting to the development
team with appropriate error descriptions.
Configuration Management Team (CM Team) is responsible for maintaining
configuration management system. This team is usually working in parallel for a
number of projects since in most cases, due to nature of the CM systems, there is
no need for a 100% engagement on a single project. Nevertheless, the duties and
responsibilities of a CM team are of huge importance for each project.

4.5. Phases in Details


4.5.1. Initiation
This is the first phase of each project. In this phase it is decided if the project
will be done or not. The decision is based on the Project Decision Report as a result
of undertaken activities at this stage.
Analysis and Design team must analyze customer’s requirements and if possi-
ble provide a solution proposal. If it turns out that requirements analysis has a nega-
tive outcome due to complexity, risks or some other reason, the analysis and design
team will suggest to the project manager to make a decision not to do the project.
An immediate consequence must not necessarily be a final “no go”, but further
negotiations with the customer could take place.
Project manager and quality assurance manager are preparing preliminary
project plans and quality assurance plans as well as analyses of risks.
164 Zvonimir Vukovi}

Figure 7: Initiation Phase

Final, and most important result of this phase is a project decision report where
it is decided is and how to proceed with the project.

4.5.2. Analysis
This phase of the project has a main goal to answer the question “WHAT
should be done?”
There are number of important activities at this phase. A user requirements
specification contains thorough description of the product requirements in terms of
its functions, interfaces and other features from the perspective of the user. A soft-

Figure 8: Analysis Phase


PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 165

ware requirements specification is one of the most important technical documents


for design and development. It describes the functionality, internal and external
interfaces and all other relevant facts about the product. Both requirements must be
reviewed externally (by the client) and internally (by development).
Project manager organizes a so-called “Kick Off” meeting where all project
team members a gathered. The people get acquainted with each other and each per-
son presents professional experiences in a form of short curriculum vitae. Project
manager gets presented also. Furthermore, the project manager to the team presents
main goals and functionality of the future product. Team members get acquainted
with their future responsibilities.

4.5.3. Design
This phase of the project has a main goal to answer the question “HOW should
the product be developed?”
At this phase there is a close cooperation of analysis and development team.
The goal is to produce architectural and detailed design of the product. Members of
analysis and design team are being consulted by development team members on
architectural questions to ensure that the architecture corresponds appropriately to
what has been required by the client.

Figure 9: Design Phase


166 Zvonimir Vukovi}

Architectural design describes the product components together with their


functions, interfaces and other features. The requirements made on the product must
be assignable to the individual product components. The content of the architectu-
ral design specification must correspond to the requirements set out in the software
requirements specification.
Detailed design specification describes the components of the architectural
design specification together with their functions, interfaces used, algorithms and
internal data structures as a basis for implementation.
Both documents get reviewed internally and, if necessary, also externally.
The project manager prepares necessary tools for development, ensures that
configuration management system is set up appropriately and prepares necessary
things for future phases (integration and test).
Quality assurance manager cooperates with test team to develop a test plan
with appropriate test cases

4.5.4. Implementation
This is a typical phase where development team plays a crucial role. Coding of
software components takes place, component tests are being executed and all other
activities are done with respect to the status and problems of development team.
Documentation team produces user manuals that will be provided together
with the product to the end user or the client. There can be a number of relevant
documents, like installation manuals, configuration manuals, interface specifica-
tions, compliance documents and similar. This depends on the nature of the product
that is being developed.

Figure 10: Implementation Phase


PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 167

4.5.5. Integration
This is a phase where code-ready components are being integrated into a sin-
gle system and tested for mutual cooperation. Usually, development team tries to
execute a number of successful requests against the system with respect to all requi-
red features of the product. As soon as this minimum level of quality is reached, the
phase is being documented and finished.

Figure 11: Integration Phase

4.5.6. Test
In the test phase the test team members and development team members have
a central role. The test team executes test cases according to previously developed
test specification and reports all errors or inconsistencies to the development team
members. The development team does error corrections in the code. Generally spea-
king, the product gets tested very thoroughly. Sometimes documentation team has
to update or correct the product documentation. Usually there are specialized tools
for error reporting needs. If such tools are available, the project manager can easily
track the progress and status of the product. Otherwise, all errors and applied cor-
rections must be documented manually. Finally, a test report is being produced that
certifies that the product has reached the necessary level of quality and conformance
to the requirements. After the review is finished, the product is being released to the
market.

4.5.7. Termination
This is a phase when finishing work is done. There are no further changes in
the product itself or in the product documentation. The project team achieves all
results of the project and identifies reusable results. Project manager writes a final
report to the higher management levels and, together with quality assurance respon-
168 Zvonimir Vukovi}

Figure 12: Test Phase

Figure 13: Termination Phase


PROJECT MANAGEMENT - SOFTWARE DEVELOPMENT METHODOLOGY 169

sible, organizes a so-called “Lessons Learned” workshop. The whole project team
is gathered once more and immediate impressions, results and experiences are dis-
cussed and documented. If the project was successful there is a further reason for
celebration. One very important goal is to identify new and useful experiences, to
document them and to make them available for all future projects.

5. Conclusion
The things presented and explained here give a rough overview of what is a
project management in a software development area and what it consists of. The
goal was to present at least most important aspects, terminology and procedures.
Every organization has some specifics that can more or less influence how the proj-
ects are managed. Furthermore, within a single organization there are rarely two so
similar projects that no significant differences exist in the way the projects are
managed.
What is very interesting in the whole area of management is that every man-
ager in any business area uses own experiences to learn from them. Also, manage-
ment techniques a full of Low Hanging Fruits (i.e. useful things and techniques that
once identified are very easy to use) that can be exchanged among managers to
improve their skills.
Project management methodology in software development area as presented
here is a subject for customization and enhancements by project managers. Those
with less experience might find some very useful things and techniques here; those
with huge experience might find it incomplete in some areas. Also, what has been
presented here is not going deep into details of how some internal procedures and
activities are executed. This is usually a matter of experience, flexibility of the team
and available technology.

Literature
Jason Charvat: “Project Management Methodologies – Selecting, Implementing and
Supporting Methodologies and Processes for Projects”, John Wiley and Sons, 2003
www.ask.org, 23.02.2004
www.managementhelp.org, 23.02.2004
Dr. Roland Gareis “pm baseline”, Project Management Austria, July 2002
Karl E. Wiegers: “Secrets of Successful Project Management”, www.processimpact.com,
25.02.2004
www.maxwideman.com/index.html, 01.03.2004
http://www.itil.co.uk, 25.03.2004
www.iime.org/glossary.htm, 29.03.2004
www.getnetwise.org/glossary.php, 30.03.2004

You might also like