2020
Group Members
Muhammad Usama shakeel FA16-BSE-017
Asif Ali Khan
FA16-BSE-005
Mohsin Ali Khan
FA16-BSE-055
Zameer Sagheer Mughal
FA16-BSE-063
Sohail Akbar
FA16-BSE-057
Assignment # 04
Group No.3
PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE HOUSES
Contents
Abstract: ................................................................................................................................................................................. 3
Key words: .............................................................................................................................................................................. 3
1.
Introduction .................................................................................................................................................................... 4
How to evaluate the project outcomes in following aspects: - Quality of products delivered - Customer satisfactions Organization benefits - Project team satisfaction................................................................................................................ 5
2.
Background/Related work ............................................................................................................................................. 5
3.
Study Design ................................................................................................................................................................... 6
Define Goal ......................................................................................................................................................................... 6
Identification of relevant papers ....................................................................................................................................... 8
Selection Criteria .............................................................................................................................................................. 10
Quality Assessment .......................................................................................................................................................... 10
Data Extraction ................................................................................................................................................................. 11
4.
Findings (Answers to Research Questions) ................................................................................................................. 11
Q1. What is the project performance evaluation criteria in small scale software houses? .......................................... 11
Q2. Classification of critical factors for project success or failure in small scale software houses................................ 15
Q3. How to demonstrate relationship between applying methods, techniques and project success in small scale
software houses. .............................................................................................................................................................. 20
Q4. How to evaluate the project outcomes in following aspects: - Quality of products delivered - Customer
satisfactions - Organization benefits - Project team satisfaction ................................................................................... 28
5.
Conclusion: ................................................................................................................................................................... 34
6.
References: ................................................................................................................................................................... 35
PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE HOUSES
Systematic Literature Review for PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE
HOUSES
Abstract: Small and medium-size enterprises (SMEs) involved in software development often experience
problems in mastering their development process, especially smaller companies. This
can result in a decreased efficiency leading to problems such as time/cost overruns or failing
to address functional and non-functional requirements (reliability, performance, usability,
etc.). Globally, this can reduce significantly the customer satisfaction and hamper the
enterprise growth potential. In this paper, we report about a survey to assess more precisely which and
how SMEs are affected by these problems. The survey was driven on small scales software
houses lightweight standard focusing on very small entities (VSEs) developing software
whose internal IT department is less than 25 people. This represents a very large portion of
SMEs in business. In particular, survey results highlight the most frequent issues and how
they are linked to some organization/project characteristics. The survey is based on a free
online self-assessment consequently, in addition to identifying issues encountered by
enterprises it is also possible to infer a set of quick-win recommendations to solve these
issues. We could also cross-check the relevance of small scale software houses
recommended tasks and activities in comparison with those already in place at companies
participating to the survey. Our results are also compared with those reported by other
surveys targeting both large and small companies.
Key words:
Project Management
Small Project Management
Small Scale Project Management
Small Scale software House
Software process improvement
Small and medium-sized software Project Management
Software process improvement
Improvement models
1. Introduction
Software process improvement is a demanding and complex undertaking. To support the
constitution and implementation of software process improvement schemes and projects, the
Software Engineering Institute (SEI) proposes a framework, the so-called IDEAL model, which
consists
of
five
phases
and
which
provides
a
structured
approach for continuous improvement.
This model is based on the SEI’s experiences with their governmental and industry customers
in the US. These are usually very large organizations. However, most software enterprises,
even in the US, but more so in Europe and other parts of the world, belong to the category of
small and very small software enterprises. Yet, although vital for both academics and
practitioners in the field, insights about software process improvement in general and the use
of such a model as IDEAL in minor organizations is still scarce
The work presented in this article wants to contribute to that body of knowledge. We have
therefore investigated the suitability of the IDEAL model for small software enterprises and
report our experiences of deploying the approach in a young and small Danish software
company. The approach was tailored to meet the organization’s needs and this resulted in the
successful completion of a first improvement cycle.
The aim of the undertaking was to change the practices in the involved organization, thus the
research approach applied falls into the category of action research [3]. The authors
participated, each to a different extent, actively in the process as change agents and mentors
for the intended alterations. In addition to the involvement in the project, observations,
informal conversations, formal interviews, official meetings and document studies were used
as methods for collection of the data, on which this article is based.
The article is structured as follows. In the next section the IDEAL model is explained in more
detail. Then, the course of the project and the application of the model are presented. Finally,
the alignment process and the content of the adjustments and their impact on the
improvement project as a whole are discussed and the case is reflected on the background of
current knowledge about managing software process improvement as organizational change.
Q1
What is the project performance evaluation criteria in small scale
software houses?
Q2
Classification of critical factors for project success or failure in small scale
software houses
Q3
How to demonstrate relationship between applying methods, techniques and
project success in small scale software houses
Q4
How to evaluate the project outcomes in following aspects: - Quality of products
delivered - Customer satisfactions - Organization benefits - Project team
satisfaction
Overview:
Software process improvement is a demanding and complex undertaking. To support the
constitution and implementation of software process improvement schemes the Software
Engineering Institute (SEI) proposes a framework, the so-called IDEAL model. This model
is based on experiences from large organizations. The aim of the research described here
was to investigate the suitability of the model for small software enterprises. It has
therefore been deployed and adjusted for successful use in a small Danish software
company. The course of the project and the application of the model are presented and
the case is reflected on the background of current knowledge about managing software
process improvement as organizational change.
2. Background/Related work
Several studies have shown how difficult is to share Software Engineering knowledge. SE
has been traditionally taught through lectures. Blackboards and slide presentations are
used as a support to the explanations. In addition, students hould take part in a fictitious
project, which has little or no connection to the traditional one to teach SE and also
motivate students to engage in the learning process, that is, become active. Several
authors have defined how to remove complexity in teaching se through reading and
projects. The aim of active learning is to provide opportunities for learners to critically
think about content through a range of activities that help prepare learners for the
challenges of professional situations.
In this sense, PIM involves deep learning, as it focuses on real-world problems and
challenges and relies on problem solving, decision making and investigative skills. These
characteristics are suitable for improving the teaching of Software Engineering. Learning
SE and how to apply your approaches throughout a software project can be a key factor
in being successful. However, the success of a project requires more than knowing SE and
how to apply it, it requires input from a variety of groups including the client, the project
team, the project manager, the organization, the producer and the end user. Each party
has a role in defining and determining success and they all have specific tasks and
responsibilities that they must fulfill in order to achieve success. Implementation of
project will be managed by project team. Right management techniques are necessary
for team to assure that planning, controlling and communication systems are all in place.
Without these systems the coordination and control of all individuals and resources
within the team is difficult.
3. Study Design
Define Goal
The main point of this chapter is to define the goal and scope of the project so clearly that
measuring progress is easy, and that there is no ambiguity that the project goals have
been achieved.
There are several techniques and tools available to the project manager to define the goal and
scope clearly.
Among them is the Is / Is Not technique, and the SMART goal checklist.
Upon completion of this chapter, the reader should be able to:
•
•
•
•
•
•
Explain why project planning is valuable
Describe the value and contents of a project charter, scope of work
statement, and software project management plan
Create useable goal and objective statements
Explain how to make crisp clean boundaries around the project’s scope
Describe the five project process steps for any project, and how they relate
to the product processes of business and software development
Show how the Project Charter, Statement of Work (SOW), Software
Project Management Plan (SPMP), and Software Requirements
Specification (SRS) relate to each other
Identification of relevant papers
IEEE
Direct Science
No.
Paper Title
Q1
Q2
Q3
Q4
Q5
Year
ACM
No.
Paper Title
Q1
Q2
Q3
Q4
Q5
Year
Q2
Q3
Q4
Q5
Year
SPRINGER
No.
Paper Title
Q1
Selection Criteria
We have selected the paper from the top 4 most reliable repositories:
I.
II.
III.
IV.
Springer
ACM
IEEE
Science Direct
Our paper range form 2010-2020. Most of paper we have selected are related to our topic
known as “Project Management on small scale software house”.
We have validated all the data we have included in our systematic literature review and have
no Redundancy in this SLR.
Quality Assessment
No of Reserach Papers
5
0
2010
2011
2012
2013
2014
Journal Paper
2015
2016
Conference Paper
2017
2018
2019
Data Extraction
Research Strategy
4. Findings (Answers to Research Questions)
Q1. What is the project performance evaluation criteria in small scale software houses?
An incomplete vision of project performance is directly related to fulfilling the
original goals of time, cost and quality. Therefore, the work of Baker, Murphy and
Fisher (1983), which showed that broader performance criteria are used by
professionals, plays an important role in various projects. They proposed the
concept of perceived success when they observed in their study that projects that
did not meet their original goals of cost, schedule and quality were not
necessarily perceived as failed projects by the people involved in the
development of the projects. Thus, a project's success is linked to the perception
of those involved (stakeholders) regarding the performance of the project.
Figure 1- Model of Project of Success. Adapted from Pinto and Slevin (1986)
success of project management (process view) and product success (product view). The
success of the process is linked to the classical aspects of performance (time, cost and quality
technical specifications), stakeholder satisfaction and development, and quality management
process. This view leads to the following performance criteria:
•
anticipate project requirements, meet project needs, use resources efficiently;
•
communicate effectively and resolve of cases in a timely manner;
•
establish effective coordination of and relationships between stakeholders, engage in
teamwork and in participatory and consensual decision making;
•
minimize scope changes and eliminate disturbances in the organization (related to work
process and culture);
•
complete project with no post-closing problems and identify and solve problems during
project execution.
The success of the product is evaluated using the following criteria:
•
achieves organizational objectives according to strategic buyer / project sponsor;
•
meets needs and purposes of users purposes and is appropriate for use;
•
meets needs of other stakeholders of the project product.
Figure 2 - Importance of factors of performance over time. Adapted from Pinto and
Slevin (1986)
all the influences and can assess compliance with the overall objectives and
benefits. Wateridge (1995) examined over 100 projects to determine the success
criteria and constraints used in the design of information technology (IT).. While
the author claims to have found broad consensus among stakeholders of IT
projects, there is some disagreement regarding the inclusion of meeting deadlines
and budgets within the definition of success criteria. The author noted a variation
in the criteria used in the performances among projects considered to be successful
and those considered to be unsuccessful. For projects deemed to be successful,
meeting the established quality specifications and achieving commercial success
were considered to be more important by project managers, while with respect to
project failures, compliance schedules and budgets were the most cited factors that
contributed to a lack of success. Users, in general, are more concerned with
ensuring a project's end result.
(*) Third parties include local and national authorities, media, environmental
groups, general public, etc.
Figure 3 - Scope of project success and success of project management. Adapted
from Munns and Bjeirmi (1997)
It is interesting to note the consistency of this result with that of Baker, Murphy
and Fisher (1983), who also found that the factors that affect the perception of
success are not (exactly) the same as those that affect the perception of failure.
Wateridge (1995) also emphasizes the importance of establishing a priori criteria
for evaluating performance among project stakeholders. He recalls that a manager
is only able to treat adequately the constraints of project success when a consensus
exists among stakeholders on the success criteria applied to the project.The
concept of success used by Dvir et al. (1998) has two dimensions: benefits
perceived by consumers and fulfillment of project goals (design). In contrast,
Shenhar et al. (2001) do not recognize the existence of two distinct concepts of
success - success and the success of product design - and instead defend the
premise that the relative importance of the dimensions of project success change
over time. They identify the following dimensions of success:
• Project efficiency (meeting deadlines and budgets);
• Impact on consumer (customer satisfaction and product quality);
• Success of the business (revenue generation, profit share and other benefits
derived by the mother organization);
• Preparation for the future (developing organizational infrastructure and / or
technology for the future).
Q2. Classification of critical factors for project success or failure in small scale software houses.
Critical success factors (CSFs)
While in comprehensive literature reviews i.e. based on case studies, experience reports, research articles and
books. We identified ten critical success factors
Categories
88%
Senior Management Commitment
1
71%
Staff Involvement
2
53%
Exprience Staff
3
53%
SPI awareness and Implementation
4
41%
Training and mentoring
5
35%
Allocation of Resources
6
35%
Communication and Collaboration
7
29%
SPI goals and Objective
8
29%
Organization Culture
9
29%
Organization Politics
10
The above identified CSFs are describing below in details,
Senior Management Commitment
Senior management commitment is most cited factors in the available literature
(Niazi et al , 2006 ; Dyba, 2005 ; Rainer and Hall, 2001 ; Stelzer and Melis, 1999 ;
El Emam et al, 2001 ;
Rickart, 1979 ; Montoni and Rocha, 2007 ; Woong, 2004 ; Goldenson and Herbslebs , 1995 ;
Badoo and Hall , 2002) & Dorenbos and Combelles , 2004). These researchers use different key
words to define the “management commitment” term, for example, higher management
commitment, executive support, top down commitment etc. However, all of researchers tried to
share their findings about the role of senior management commitment and its importance in
Software process Improvement. Different group of practitioners belonging to industries with
best practice concepts and approaches for successful implementation of SPI and initiative taken,
is highlighted in their empirical studies results and, how truly commitment and involvement of
senior management abled them for successful implementation of SPI initiative program was
pointed out.
To be successful in the SPI process the senior management should have a broader picture of
their resources required to conduct the process improvement assessment initiative, and
appropriately need to plan, sponsor, provide funding and accomplish the actions plan (Stelzer
and Melis, 1999). The Goldenson and Herbslebs (1995) study shows that almost 100% create
actions plans and 90% for Process Action Team (PAT) to assure the implementation of actions
plans. This study also confirmed that the monitoring of the progress by higher management is
the most vital factor in successful implementation of SPI.
Staff Involvement
Staff involvement is among a key factor which helps to facilitate successful SPI program. This
is agreed by many researchers such as (Niazi et al, 2006 ; Dyba, 2005; Rainer and Hall, 2001 ;
Stelzer and Melis, 1999 ; Hall et al, 2002 ; Montoni and Rocha, 2007; Woong, 2004 ; Goldenson
and Herbslebs, 1995 ; Badoo and Hall, 2002 ; Dorenbos and Combelles, 2004). These authors
explore different aspects of staff involvement CSF in their studies and provide some in-depth
knowledge and idea about how the staff participation and involvement leads us to successful
implementation of SPI and in the evaluation process; and assessment of its initiative in change
management. The Dyba (2005) defined staff involvement factor as “the extent to which
employees use their knowledge and experience to decide, act, and take responsibility for SPI
and this is positively associated with SPI success” while, Stelzer and Melis (1999) defined staff
involvement as “ the degree to which staff members participate in the improvement activities “.
So, in the light of above researchers definitions it can be said that staff involvement is the amount
of interest taken by the employees in the adoption of responsibility to participate in SPI initiative
where they use their skills, experience and knowledge for successful implementation of SPI
program and initiative.
For successful SPI program, staff involvement is extremely essential that all the personnel
belonging to software development should be encouraged for participation in the change process
and this can be achieved by forming workgroups. The software organizations require promoting,
engaging and maintaining collaboration within the workgroups and between Project teams. The
involvement of the group’s members should be administered properly so that every staffs feel the
improvement in their work and sense of responsibility of contributing towards the organization
goals (Dyba, 2005 ; Goldenson and Herbslebs, 1995; Stelzer and Melis, 1999 & Guerrero, 2004).
The workgroup address is the Key Process Area and, the scheme for the design enhancement
under the guideline of SEPG.
Experience Staff
The number of authors on the basis of their collected sample studies data, emphasis on how a
software process skills, experience and staff expertise can play a key role in successful
implementation of SPI program. In experienced staffs, practitioners consider hurdle in SPI and
emphasize to equip them with the necessary training that transfers the right SPI skills that enable
them to mastery it in use. This training should make awareness in the in-experienced staff about
the critical technologies that is required for SPI initiatives. The main goal for this training should
be to transfer the knowledge of SPI inter-related activities with business objective and
organization goals. (Niazi, 2009)
Nonetheless, some of the authors defined lack of experienced staff as a barrier in SPI:
•
In the organization different staffs treat differently, some of them give more
priorities and importance than others this is due to reasons based on their
experience and expertise. The organization lacks experienced staff and due to
these reasons, they recruit people who have just graduated from the
universities and don’t have previous experience. This skills and expertise
continuously need to be improved and increased by means of training. (Rainer
and Hall, 2003)
•
Due to lack of prior significant development experience of the change agent,
who is engaged in SPI, their resulted approach towards process improvement
is unrealistic and impractical. When such change agents try to implement a
particular process, model or approach fails to tailor it that is suited to
organization culture and aligned with organization business goals. Because,
they don’t understand themselves, the software development process and in
what context they used it. This leads towards failure and the results, which
are achieved through the process, is neither accepted nor followed. (Moitra,
1998)
SPI practitioner said that process initiative could only be successful if the staff involved in the
process has detail and comprehensive understanding of SPI process and related to business.
Experienced staff should need to be involved in SPI initiative because, they have all the necessary
skills, experience, knowledge and firsthand experience with SPI implementation. By involving
them, we can avoid re-documentation and real issues can be resolved on the spot. Below mention
are some of the guidelines suggested by the practitioner for successful implementation of SPI.
•
Only those people need to be selected for the SPI activities that have good
record of accomplishment of different SPI projects.
•
Organization should need to develop a well-written training policy according
to their needs for SPI training.
Responsibilities of each member should be clear and the member should be
assigned SPI implementation activities.
•
•
A mechanism for monitoring the SPI progress against the each staff members
should be established and maintained. (Niazi ,2009)
SPI awareness and Implementation methodology
According to Niazi (2009) to fully understand the benefits of SPI, there is need to sponsor the
SPI awareness program i.e. “ROI and impact”, practitioner belief that SPI implementation is
basically taking on board the organization best practices. Consequently, it is essential to address
the SPI awareness activities and transfer the share knowledge among different groups who are
actively engaged in process activities (Niazi, 2009).
In the SPI initiatives process program all the stakeholders should get involved and,
comprehensive awareness and its benefits should be communicated to them. Because, the SPI
implementation cannot be successful if adequate awareness was not provided to all the
stakeholders in advance.
In order to avoid barrier in SPI implementation, practitioner suggested below awareness guidelines
•
The benefits achieved through SPI implementation need to be communicated before the implementation
process.
•
•
•
Higher management needs to be informed about the resource required and the
amount of long benefits received.
The role and responsibilities of staff members should be clear before
implementation and, proper planning should be completed in order to manage
and carry on SPI awareness events within the organization.
Planning is also required to make SPI an organizational culture
In order to avoid barrier in SPI implementation, practitioner suggested
the following guidelines:
•
Technologies (such as tools for planning, monitoring and reporting projects )
should be used while developing SPI implementation methodology
• In the pilot projects, SPI implementation methodology should be tested and
staff member should be convinced with the performance of methodology.
• Necessary training should be provided that transfers the appropriate skills and
understanding that provide surety of successful use of methodology.
• Methodology needs to be continuously evaluated with the aim to implement in
the whole organization. (Niazi ,2009)
Communication and Collaboration
Communication and Collaboration are considered to be amongst the most influential factors,
which affect the SPI process. Dyba defined these factors as:
“Degree to which communication efforts precede and accompany the improvement program
(communication) and degree to which staff members from different teams and departments
cooperate (collaboration)”
The lack of effective communications occurs when the change agent and the management are not
able to communicate effectively the benefits achieved from the process improvements.
Consequently, staffs involved in the mechanism don’t have clear information about their
contribution, roles and the achievements. When the change initiative happen, people who are
involved in the process always want clear answers of “the reasons for change” and “benefit they
get” from the process initiative (Guerrero, 2004). The problem of inadequate cooperation among
the teams and divisions occur in software companies like QA teams that are not suitably well
involved in the development process. Thus, conquering process improvement activities stresses
collaboration and, the collaboration project includes:
“Joint process descriptions, workshops, and special interest groups. Joint activities help
staff members discover unexpected similarities in products and processes.”
Majority of SPI practitioner’s belief that inadequate supply of staffs, time and other resources
are the major barriers in successful SPI implementation (Hall et al, 2002). Management often
fails to understand the real investment of the resources required for process initiatives and often
agree without having a clear-cut picture of the resources required. In practical terms, some of the
management does not consider SPI as an actual or separate project. Thus, they hesitate to allocate
resources.
Niazi quoted some Authors and studies given below who consider that lack of resources is the main
barrier in SPI implementation:
•
•
•
Florence discuss in the lesson learned , MITRE Corporation succeeded to
achieved CMM level 3 due to adequate level of resources provided but, fails
to achieve CMM level 4 due to the reasons that the resources were not
provided as required.
Kautz and Nielsen discussed SPI implementation and thought that it did not
succeeded because the project managers are not willing to provide resources
for their own projects and, for others improvement activities.
Laporte and Trudel in Lesson learned from Oerlikon Aerospace described that
it is important to estimate and provide resources. Otherwise, announce end
of project and discontinue adopting SPI program. (Niazi , 2009)
SPI objectives and goals
It is necessary for organization to set realistic & relevant objectives and goals for SPI. These
objectives need to be crystal clear and, SPI managers need to communicate to all the actions
groups within the organization.
Establishing the realistic objectives means that goals seem to be achieved in the near future and
its objectives and goals are not too ambitious. It demand that the expectations should be clear
and the expected results need to be communicated at all the levels of the organization (Stelzer
and Melis, 1999 ; Becham, 2003). “.…Therefore, successful SPI program is one, in which SPI
goals and policies have been clearly aligned with business goals, identifying the nature and
direction of any SPI actions” (Dyba, 2005). The result of this combined effort towards the
“common objectives”, ”to focus energy” and “to motivate people”. These factors citied 44% of
the ISO cases and 87% of the CMM cases. Mangers who don’t set the realistic objectives or too
much goals merely dishearten their subordinate staff. The organizations that while taking the
process initiatives do not defined relevant objectives and goals basically, in the long term, end up
on fuzzy goals. This approach neither help fully to motivate the staffs nor for successful
improvement efforts. (Stelzer and Melis, 1999)
Organizational Politics
Several authors consider politics as barrier in SPI implementation because SPI aim is to bring a change in the
organization and people do often resist the change. This is because SPI initiatives goals may suit to one group’s
goals but collide with other groups or teams goals. The reason is that the organization comprises of different
groups and they have different priorities and goals that do not match with the SPI initiatives goals and this
leads to oppositions from those people. ”There are many factors that can trigger organization politics, such as
reallocation of the resources, promotions opportunities, low trust, times pressure, and role ambiguity.”
(Niazi, 2009). The authors Goldenson and Herbsleb (1995), El-Emam et al (2001) and Becham
(2003) also found that organizational politics is very common in the organization and create
hurdle in successful process implementation activities. Author Moitra also identified the
underlying problems and difficulties of SPI change management process and stated that politics
is one of the main cause in change management efforts and a strong barrier in successful process
improvement initiatives (Moitra, 1998).
Organizational Culture
Culture difference exists between different countries that are not necessarily suited or accepted
by people living in other countries. Moreover, specific cultures adopt, without considerations of
that organization, original values from these countries customs and practice. These may be found
as a problem in existing organization’s cultures (Becham, 2003). Organizations will
continuously face problems in implementation and deploying of best practices; majority of these
problems belong to “people, group, team and community culture and behavior” (Dorrenbos
and Combelles, 2004). All these needs to be considered when SPI improvement initiative steps
should be taken. So that any suggestion, implementation and deployment activities do not adopt
any such change of management methods which oppose the culture. The failures in
consideration of culture impact while designing the change management program, leads towards
process adoption by the groups or people in unproductive manner or, totally neglect the
adoption. This consequently affects the process improvement program and overall productivity
(Guerrero, 2004). According to Moitra neglecting to anchor change in corporate culture is main
reasons for failure in process improvement related change efforts. (Moitra, 1998)
Q3. How to demonstrate relationship between applying methods, techniques and project
success in small scale software houses.
Helpful Project Management Methods and Techniques
Before we dive in, you should remember that all of these methods will help you organize and structure
your project. There’s no right answer.
Your chosen method depends on you and your project.
I.
Work Breakdown Structure (WBS)
A WBS transforms big project
activities into chunks of
manageable tasks you and your
team can easily understand and
complete.
So if you were constructing a
house, like in the example
above, you’d divide the work
into segments such
as: internal work, external work,
and building the foundation.
From there, you’d break down
the work further into work
packages, based on levels and
task
dependencies.
Who should use WBS? WBS
can be used as a project
management technique, but it
can also be a tool, regardless of the technique you end up choosing. It will help you understand
all the tasks and resources that go into producing the final deliverable.
How to get started? Start from the final deliverable defined by the project, and then define the
tasks you and your team will need to complete in order to finalize the project.
Divide the tasks into work packages. Stop only when you’re sure that you can’t break down the
lowest- level work packages into smaller chunks of work.
Gantt Charts – One of the First Project Management Techniques
Gantt charts have been around for a very long time, and they’re still a great project
management technique for beginners and pros alike.
It’s another technique that emphasizes visuality.
It’s a visual representation of all the tasks your team has to complete in order to wrap up the
project, visualized together with time spans.
You’ll be able to see task dependencies, how long each task will take, as well as how its
duration will affect the start dates and deadlines.
Who should use Gantt charts? While you can use Gantt charts as a standalone project
management technique, you can also use them as an organizational tool, regardless of your
chosen method.
How to get started? The majority of project management tools offer Gantt chart views,
so all you have to do is enter the data, and you’ll get a visualization immediately. It’s good
to have a Work Breakdown Structure prior to that, so you can accurately define tasks you’ll
add to your Gantt chart.
II.
Critical Path Method (CPM)
The Critical Path Method is one of project management techniques used to accurately
schedule all project activities.
What you’ll be actually doing is calculating the critical path – the shortest route to
project completion, and arranging tasks accordingly. It’s also a great way to establish
task dependencies.
You can combine CPM with PERT (Program Evaluation and Review Technique) to create
three task completion time estimates:
•
•
•
Shortest amount of time
Realistic amount of time
The longest amount of time
Who should use the Critical Path Method? CPM is best suited to more complex projects
with a lot of task dependencies. However, just like with WBS and Gantt Charts, you can use
them as tools, not just as project management techniques.
How to get started? Define all the tasks that have to be completed. Then, establish task
dependencies (Task B can’t be completed until Task A is completed), and create diagrams
for different duration estimates.
III.
Waterfall / Linear
Waterfall is one of the oldest project management techniques.
If you use this project management technique, activities and tasks will linearly flow through
5 phases:
•
•
•
•
•
Requirements (Get all the necessary documentation)
Design (Use a WBS to create a list of tasks)
Implementation (Complete tasks)
Verification (Review the deliverables)
Maintenance (Maintain and modify if necessary).
Who should use the Waterfall method? Waterfall works great for projects with distinct
phases that require very few iterations throughout the project life cycle. If you think you’ll
need to modify certain things and re-discuss the scope or the budget of the project, Waterfall
is not for you.
How to get started? Make a list of all the resources and deliverables you’ll need in each
phase. Preparation is key – make sure you have everything covered in the first, project
initiation and requirements, phase.
Kanban – The Simplest Project Management Technique
IV.
Kanban is one of the easiest project management techniques for first-time project
managers. The whole philosophy is in creating three columns:
•
•
•
To-do
Doing
Done
Then, you and your team can simply shift tasks from one column to another as you complete
them.
Who should use Kanban? Anyone. It’s great as a tool, or as a stand-alone project
management technique. It’s particularly successful for simpler projects, or project teams
that are prone to multitasking.
How to get started? We recommend getting visual project management software which
offers Kanban boards. Then, make a list of tasks, and assign them to different team members.
When you complete a certain task, move it to the ‘Done’ column.
V.
Scrum – Best Agile Project Management Technique
Finally, if you want to make sure every project deliverable comes out phenomenally, you
should consider using Scrum, one of the most popular Agile methodology techniques.
With Scrum, you’ll be working in sprints.
During each sprint, you’ll work on a particular deliverable/feature.
Sprints shouldn’t last longer than 2 weeks, and you should hold daily status update meetings.
After the sprint, you should hold a review meeting, make suggestions for improving the
next sprint, and keep going.
It’s as simple as that!
Who should use Scrum? Primarily, software development project teams, and project
teams that work on complex projects requiring multiple iterations throughout the project
life cycle.
How to get started? Break down the project into specific deliverables / features. Work on
one deliverable at a time during your sprint, and schedule them with task dependencies in
mind.
Ways To Measure Project Success
Project managers often wonder if they are measuring the right things on a
project. It's difficult to know how much time to spend evaluating past
performance and how much time to spend on keeping the work moving
forward.
Of course there are many indicators of project success, but what do you need
to be measuring while the project is in motion?
At various points during the project you want to evaluate five points:
schedule, quality, cost, stakeholder satisfaction and performance against the
business case. You should be doing this informally anyway. A formal project
evaluation is of use during the end of a phase or stage as it can give you a
clear indication of how the project is performing against the original
estimates. This information can then be used to grant (or withhold) approval
from moving on with the next chunk of work.
Let's look at the five items you should be evaluating.
I.
Schedule
Project management success is often determined by whether or not you kept to
the original timeline. Experienced project managers know how hard that is, but it's
a little bit easier if you continually evaluate your progress as you go.
You'll update your project schedule regularly - I recommend at least weekly. The
schedule evaluation is something you can do more formally at the end of the stage
or phase, or as part of a monthly report to your senior stakeholder group or Project
Look at your major milestones and check if they still fall on the same dates as you
originally agreed. Work out the slippage, if any, and how much of an impact this
will have on your overall project timescales
II.
Quality
The end of a project phase is a good time for a quality review. You can check both
the quality of your project management practices - are you following the change
management process every time and so on - and also the deliverables.
A quality review can evaluate whether what you are doing meets the standards
set out in your quality plans. Best find out now before the project goes too far,
as it might be too late to do anything about it then.
III.
Cost
Many executives would rate cost management as one of their highest priorities
on a project, so evaluating how you the project is performing financially is crucial.
Compare your current actual spend to what you had budgeted at this point. If
there are variances, look to explain them. You can use a project dashboard to
check your actual spend in real time.
You'll also want to look forward and re-forecast the budget to the end of the
project. something it is better to know about now.
IV.
Stakeholder Satisfaction
Your wider team - your stakeholders - are essential in getting much of the work
done, so it's worth checking in with them. Find out how they are feeling about
the project right now and what you could be doing differently.
This is a difficult measure to document statistically, although there's nothing to
stop you asking them for a rating out of 10. Even if you are evaluating their
satisfaction subjectively, it is still a useful exercise. If you notice that stakeholders
are not fully supportive, you can put plans in place to engage them thoroughly to
try to influence their behavior.
V.
Performance to Business Case
Finally, you'll want to go back to the business case and see what you originally
agreed upon. How is your project shaping up? Check that the benefits are still
realistic and that the business problem this project was designed to solve does
still exist. It happens - project teams work on initiatives that sound great but by
the time they are finished the business environment has moved on and the
project is redundant. No one bothered to check the business case during the
project's life cycle and so no one realized that the work was no longer needed.
Don't work on something that nobody wants! Check the business case regularly
and evaluate it in light of the current business objectives.
You can add other items to this list. In fact, it should reflect what is important to
you and your team - you should be evaluating things that matter, so feel free to
add extra element or ditch some of the ones that you are less worried about. If you
need help working out what's important, this article about how to set up project
tracking will help.
Q4. How to evaluate the project outcomes in following aspects: - Quality of products delivered Customer satisfactions - Organization benefits - Project team satisfaction
We can Evaluate the Project outcomes in following ways:
Quality of Product
Project quality is a key determiner of customer satisfaction...which in turn is a
key determiner for project success. Therefore, nothing about quality should be
taken lightly on the project. Before a project manager can plan for quality, he
must know what the quality expectations are. Specifically, what are the quality
standards of the performing organization and which quality standards are
applicable to the project? As part of the planning processes, the project manager
and the project team must identify the requirements of planning, determine how
the requirements may be met, and identify the costs and time demands to meet
the identified requirements.
One of the key principles of project quality management is that quality is planned
in, not inspected in. Planning for quality is more cost-effective than inspecting
work results and doing the work over, or correcting problems to adhere to quality
demands.
The project manager must consider the cost of achieving the expected level of
quality in contrast to the cost of nonconformance. The cost of quality includes
training, safety measures, and action to prevent poor quality. The cost of
nonconformance can far outweigh the cost of quality: loss of customers, rework,
lost time, lost materials, and danger to workers.
Results of Quality Control
Quality control should, first and foremost, result in quality project output. Next,
it should also promote quality improvement. The project manager and project
team, based on the results of the tools and techniques to implement quality
control, apply corrective actions to prevent unacceptable quality and improve
the overall quality of the project management processes. And keep in mind that
these quality tasks must also be part of your project schedule that you revise and
track using a tool like Seavus’ Project Viewer in conjunction with MS project.
The corrective actions the project manager and the project team want to
incorporate into the project may require change requests and management
approval. The value and importance of the change should be evident so the
improvement to quality is approved and folded into the project. In addition to
quality improvement, there are other results of quality control:
Acceptance decisions. Results of work are either accepted or rejected. Rejected items typically
mean rework
Rework. Nonconformance to quality results in rework. Rework costs time and money and
contributes to projects being late, over budget, or both. It is always more cost effective to do
the work right the first time than to do it correct the second.
Completed checklists. If the project is using checklists to confirm the completion
of work, then the completed checklists should become part of the project
records. Some project managers require the project team member completing
the checklist to initial the checklists as whole and complete.
Process adjustments. When results of inspections indicate quality is out of
control then process adjustments may be needed to make immediate corrective
actions or planned preventive actions to ensure quality improves. Process
adjustments, depending on the nature of the adjustment, may qualify for a
change request and be funneled through the Change Control System as part of
integration management.
Customer Satisfaction
What is customer satisfaction?
When we have a great food experience at a new restaurant, we usually want to
go back. Positive evaluations result in greater customer satisfaction, which leads
to customer loyalty and product repurchase.
That’s a customer satisfaction definition in a nutshell. But on closer inspection,
customer satisfaction is more than simply a link in a chain that leads to more
sales.
4 key customer satisfaction metrics
So how do we effectively measure customer satisfaction?
Here are 4 key customer satisfaction measurements that are critical to your
business success. They take into account the different dimensions of customer
satisfaction, such as affective (emotional) and cognitive (rationally judged)
reactions to a product or service and behavioral intentions (such as likelihood to
recommend or repurchase) as well as taking overall scores of satisfactions as
judged by the respondents.
1. Overall Satisfaction Measure (Attitudinal)
Example question: Overall, how satisfied are you with “La Jolla Grove restaurant”?
This question reflects the overall opinion of a consumer’s satisfaction experience with a
product he or she has used.
The single greatest predictors of customer satisfaction are the customer
experiences that result in attributions of quality.
Perceived quality is often measured in one of three contexts:
•
Overall quality
•
Perceived reliability
Extent of customer’s needs fulfilled
It is commonly believed that dissatisfaction is synonymous with purchase regret while
satisfaction is linked to positive ideas such as “it was a good choice” or “I am glad that I bought
it.”
•
2. Loyalty Measurement (Affective, Behavioral)
Example question:
Would you recommend “La Jolla Grove restaurant” to your
family and friends? This single question measure is the core
NPS (Net Promoter Score) measure.
Customer loyalty reflects the likelihood of repurchasing products or services.
Customer satisfaction is a major predictor of repurchase but is strongly
influenced by explicit performance evaluations of product performance, quality,
and value.
Loyalty is often measured as a combination of measures including overall
satisfaction, likelihood of repurchase, and likelihood of recommending the brand
to a friend.
A common measure of loyalty might be the sum of scores for the following three questions:
•
Overall, how satisfied are you with [brand]?
•
How likely are you to continue to choose/repurchase [brand]?
•
How likely are you to recommend [brand] to a friend or family member?
A series of Attribute Satisfaction Measurements (Affective and Cognitive)
Example question: How satisfied are you with the “taste” of your entre at La Jolla Grove?
Example question: How important is “taste” in your decision to select La Jolla Grove
restaurant?
Affect (liking/disliking) is best measured in the context of product attributes or
benefits. Customer satisfaction is influenced by perceived quality of product and
service attributes, and is moderated by expectations of the product or service.
The researcher must define and develop measures for each attribute that is
important for customer satisfaction.
Consumer attitudes toward a product developed as a result of product
information or any experience with the product, whether perceived or real.
Again, it may be meaningful to measure attitudes towards a product or service
that a consumer has never used, but it is not meaningful to measure satisfaction
when a product or service has not been used.
3. Intentions to Repurchase Measurements (Behavioral Measures)
Example question: Do you intend to return to the La Jolla Grove restaurant in the next 30 days?
When wording questions about future or hypothetical behavior, consumers
often indicate that “purchasing this product would be a good choice” or “I would
be glad to purchase this product.” Behavioral measures also reflect the
consumer’s past experience with customer service representatives.
Satisfaction can influence other post-purchase/post-experience actions like
communicating to others through word of mouth and social networks.
Additional post-experience actions might reflect heightened levels of product
involvement that in turn result in increased search for the product or information,
reduced trial of alternative products, and even changes in preferences for shopping
locations and choice behavior.
Organization benefits
Projects and programs deliver benefits and drive strategy. This is a fact not always recognized
by organizational leaders who are more focused on issues of cost and ROI than on the execution
of projects. Benefits realization is a way to change that thinking, underscore how projects and
programs deliver benefits to the business, and enable the necessary change. Adopting benefits
management can help organizations increase the value of their
investments. It requires purposeful
attention to which projects and
programs are approved—and why.
It facilitates more effective
decision
making
about
investments. In fact, organizations
with high benefits realization
maturity waste 67 percent less
money than those with low
maturity, because they have better
project performance. “It’s central
to use benefits to decide which
project ideas to invest in,” said
Chris Lawler, PfMP, Manager,
Project Portfolio Office, Mater
Health Services. “They need to be
part of the concept brief and
business case and, though a
temporary project will deliver the
outputs, the permanent part of the
organization needs to own
benefits,
be accountable, be measuring, then actively use those measures to make adjustments or to even
terminate a project that will not create the desired value.” Despite the proven value of benefits
management, the data from our 2016 Pulse of the Profession® reveals that a staggering 83 percent
of organizations lack maturity with benefits realization, raising myriad questions about how they
understand the business value of projects and programs. Our research further confirms that this
lack of maturity may be contributing to projects—including strategic initiatives—failing to achieve
their original goals and business intent; and that identifying benefits as part of the business case,
even before the start of a project, improves outcomes. Specifically, 45 percent more projects meet
original goals and business intent in organizations with high maturity in benefits realization,
compared to those with low maturity. This translates to significantly fewer dollars wasted (see
Figure 1). Those front- end discussions also help organizations understand a project’s benefits,
even when they are not immediately realized. Some benefits, especially the more intangible, may
not come to fruition for several years. So measuring return requires a longer-range view of related
business activities.
Project team satisfaction
The evaluation of team satisfaction is just as important as the assessment of customer
satisfaction. While there is a lot of research available on customer satisfaction this is not
the case for the question: how satisfied are project team members with the project
management and the project results? However, it is essential to know how our team
members evaluate project results, project management, leadership, and the team work
because their “inside views” can give us valuable suggestions where we can improve our
project management process, leadership behavior, the environment of “healthy” team
dynamics, and much more, for our future projects.
By the term “team satisfaction” we mean the satisfaction of team members of the
project team. As with customer satisfaction, here we also suggest to use interviews with
individual team members in case of smaller project teams of up to twelve people, and
questionnaires for larger teams. Both, interviews and questionnaires should cover team
work and leadership issues as well as work content and results in all phases of project
management.
Team work or collaboration within the team
Here we want to cover aspects of team work and group dynamics of the core project
management team as seen by the team members. The following questions of a team
satisfaction survey include the project manager as a team member with his / her special
role as team leader.
•
Did we set and communicate clear goals for all of our discussions?
•
Did we consistently follow those goals?
•
Did we set and agree to rules for our cooperation and communication?
•
Did we consistently follow those rules?
•
What did we do for our cross-cultural understanding?
•
Did we respect each other personally and in terms of expertise?
•
Did we listen to each other by clarifying unclear points and asking appropriate questions?
•
Did we assign all necessary roles?
•
What did we do for our development as a team?
•
How did we set up the information flow within the team?
•
How did we make decisions?
•
Did we include all necessary team members in the problem solution processes?
•
Did we include all necessary team members in the decision making processes?
•
How did we deal with tension or conflict?
•
How did we deal with mistakes (hiding them, blaming each other, learning from them,
etc.)?
•
Did we establish a culture of feedback and constructive criticism among all team members?
•
How well did we communicate with project participants and stakeholders outside the team?
•
If applicable, how well worked our virtual team communication and collaboration?
5. Conclusion:
So far, the survey has confirmed previously reported factors explaining why SME are
challenged in mastering the maturity of their IT developments. It has also more precisely highlighted
interesting facts. It also tends to show that SME are quite aware of their maturity
level and are willing to improve it (a large majority of SME asked to be kept informed
although it was not mandatory). A current limitation is the relatively small number of answers,
which is also bound to its relatively small current geographical scope. Our plan is now to
extend our survey to other countries and, based on the larger set of answers, to study if the
same observations are confirmed or need to be revised. It takes about 15 minutes to
complete and provides quick win recommendations. We warmly encourage you to spread
the information to any SME you know that might be interested.
6. References:
Brodman, J. D., D. L. Johnson (1994). What Small Businesses and Small
Organizations say about the CMM. In Proceedings of the 16th International
Conference on Software Engineering, IEEE Computer Society, pp. 331-340, May
1994.
Kautz, K. (1999). Making Sense of Measurements for Small Organizations. IEEE
Software, Vol. 16, No.2, pp. 14-20.
Argyris, C., D. A. Schoen (1991). Participatory Action Research and Action
Science Compared. In Whyte, W. F. (ed.), Participatory Action Research. Sage,
Newbury Park, Ca., USA.
McFeeley, B. (1996). IDEALSM : A User’s Guide for Software Process
Improvement. Handbook CMU/SEI- 96-HB-001. Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PE, USA.
Iversen, J., J. Johansen, P.A. Nielsen, and J. Pries-Heje (1998). Combining
Quantitative and Qualitative Assessment Methods in Software Process
Improvement. In Baets (ed.), Proceedings of the 6th European Conference on
Information Systems (ECIS), Aix-en- Provence, France, pp. 451-466, June 4-6,
1998.
Westergaard Hansen, H. , K. Thaysen (1998a). NP - Assessment Process Report
(in Danish). University of Aalborg, Institute for Electronic Systems, Department
of Computer Science, Denmark.
Westergaard Hansen, H., K. Thaysen (1998b). Process Improvement in a Small
Danish Software Company (in Danish). MSC Thesis, University of Aalborg,
Institute for Electronic Systems, Department of Computer Science, Denmark.
Kautz, K., K. Thaysen (2000). Knowledge, learning and IT Support in a Small
Software Company, in Proceedings of BPRC CONFERENCE on 'Knowledge
Management: Concepts and Controversies' 10-11, February, 2000: University
of Warwick, Coventry, UK.
Rogers, E. M. (1983). Diffusion of Innovations (3rd edition). The Free Press, New
York.
Kautz, K. (1999). Software Process Improvement in very Small Enterprises:
Does it pay off? In Journal of the Software Process – Improvement and
Practice, Special Issue on Organizational Change with Software Process
Improvement, Vol. 5.
Borum, F. (1995). Strategies for Organizational Change (in Danish). CBS
Publishing Company. Copenhagen, Denmark.
Boehm, B.W. Software Engineering Economics. Prentice-Hall Inc., Englewood Cliffs, NJ,
1981.
Curtis, B., Kellner, M.I. and Over, J. Process Modeling. Commun. ACM 35, 9 (1992),
75–90.
Deephouse, C., Mukhopadhyay, T., Goldenson, D.R. and Kellner, M.I. Software processes
and project performance. Journal of Management Information Systems 12, 3 (1996), 185–
2003.
Dion, R., Process improvement and the corporate balance sheet, IEEE Software 10, 4 (July
1993), 28–35.
Fox C. and Frakes, W., The Quality Approach: Is it Delivering? Commun. ACM 40, 6
(1997), 25–29.
Gopalakrishnan, S., Kochikar, V.P. and Yegneshwar, S. The offshore model for software
development: the Infosys experience. In Proceedings of the ACM SIGCPR Conference on The
Virtual Workplace: The Impact on Individuals, Organizations and Societies. (Denver,
Colorado).April 1996.
Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., Paulk, M., Software quality and the
Capability Maturity Model, Commun. ACM 40, 6 (1997), 30–40.
Humphrey, Watts, Snyder, Terry R. and Willis, Ronald R., Software process improvement
at Hughes Aircraft, IEEE Software 8, 4 (July 1991), 11–23.
Kraut, R.E. and Streeter, L.A. Coordination in large scale software development. Commun.
ACM 38, 7 (1995), 69–81.
Krishnan, M. S., C. H. Kriebel, S. Kekre, and T. Mukhopadhyay, An empirical analysis
of cost and conformance quality in software products. Management Science 46, 6 (June
2000)745–759.
Mukhopadhyay, T. and Kekre, S. Software effort models for early estimation of process
control applications. IEEE Transactions on Software Engineering 18, 10 (1992), 915–924.
Paulk, M.C., Curtis, B., Chrissis, M.B. and Weber, C.V. Capability Maturity Model for
Software, Version 1.1. Software Engineering Institute, CMU / SEI-93-TR-24, (Feb. 1993).