Project Management - Software Development Methodology
Project Management - Software Development Methodology
Project Management - Software Development Methodology
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
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.
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.
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.
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.
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.
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:
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.
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.
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.
6 www.maxwideman.com
160 Zvonimir Vukovi}
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
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-
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.
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.
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.
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}
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