Module Code & Module Title

CC7176NI Software Project Management

Assessment Weightage & Type

50% Individual Coursework

Semester
2019 Spring

Student Name: Rumesh Udash

London Met ID: 17031235
College ID: NP01MS7a190015
Assignment Due Date: Sept 5th 2020
Assignment Submission Date: Sept 5th 2020
Word Count (Where Required):

I confirm that I understand my coursework needs to be submitted online via Google Classroom under the
relevant module page before the deadline in order for my assignment to be accepted and marked. I am
fully aware that late submissions will be treated as non-submission and a mark of zero will be awarded.
Table of Contents
Chapter 1: Memorandum...................................................................................................6
Chapter 2: Methodologies.................................................................................................7
2.1 Software Development Approaches........................................................................7
2.2. Methodologies.........................................................................................................9
2.2.1 Kanban............................................................................................................10
2.2.2 Dynamic System Development Method (DSDM)............................................11
2.3 Selection of DSDM.................................................................................................16
2.4 Rejection of Kanban...............................................................................................17
2.5 Conclusion.............................................................................................................18
Chapter 3: RACI Matrix....................................................................................................19
3.1 RACI Matrix on Process Level...............................................................................19
3.2 RACI Matrix on Activity Level.................................................................................23
Chapter 4: Project Plan....................................................................................................27
4.1 Team Structure......................................................................................................27
4.2 User Stories...........................................................................................................29
4.3 Prioritization and Estimation..................................................................................30
4.4 Timebox Planning..................................................................................................31
4.5 Project Plan..............................................................................................................33
Chapter 5: Project Brief...................................................................................................34
5.1 Project Definition....................................................................................................34
5.1.1 Background.....................................................................................................34
5.1.2 Project Objective.............................................................................................34
5.1.3 Desired Outcomes...........................................................................................35
5.1.4 Project Scope and Exclusions.........................................................................35
5.1.5 Constraints and Assumptions.........................................................................35
5.1.6 Project Tolerances..........................................................................................36
5.1.7 The User and Any Other Interested Parties....................................................36
5.1.8 Interfaces.........................................................................................................36
5.2 Outline Business Case...........................................................................................37
5.2.1 Reason............................................................................................................37
5.2.2 Benefits Expected...........................................................................................37
 5.2.3 Risks................................................................................................................38
5.2.4 Costs...............................................................................................................38
5.2.5 Time..................................................................................................................38
5.3 Project Product Description...................................................................................38
5.4 Project Approach....................................................................................................39
5.5 Project Management Team Structure....................................................................39
5.6 Role Descriptions...................................................................................................39
Chapter 6: PRINCE2 and DSDM.....................................................................................39
6.1 PRINCE2................................................................................................................39
6.2 DSDM.....................................................................................................................42
6.3 Critical Comparison of PRINCE2 and DSDM........................................................42
6.3.1 Integration in Process Level............................................................................43
6.3.2 Integration in Roles.........................................................................................45
6.3.3 Integration in Deliverables...............................................................................47
References.........................................................................................................................51
List of Figures
Figure 1 : A demo of Kanban Board (Non-Electronic) (Hygger.io, 2020)........................11
Figure 2 : The 7 Phases of DSDM...................................................................................13
Figure 3 : The DSDM Team Model (Agile Business Consortium, 2019).........................15
Figure 4: RACI Matrix on Process Level.........................................................................19
Figure 5: RACI Matrix on Activities Level........................................................................24
Figure 6: Team hierarchy structure of the project...........................................................28
Figure 7: PRINCE2 Principles.........................................................................................40
Figure 8: PRINCE2 Project Lifecycle...............................................................................41
Figure 9: PRINCE2 and DSDM Positioning....................................................................43
Figure 10: PRINCE2 and DSDM Combined Project Structure........................................46
List of Tables
Table 1: Comparison between Agile and Traditional Software Development
Methodologies (M.A. Awad, 2005)....................................................................................8
Table 2: Organizational Roles of the Team Members.....................................................29
Table 3:Timebox 1 Plan...................................................................................................32
Table 4:Timebox 2 Plan...................................................................................................32
Table 5: Timebox 3 Plan..................................................................................................32
Table 6: Timebox 4 Plan..................................................................................................32
Table 7: Timebox 5 Plan..................................................................................................33
Table 8: Timebox 6 Plan..................................................................................................33
Chapter 1: Memorandum
Date: 4th Sept, 2020
From: Mr. Rumesh Udash, Project Manager, Altruistic Inc.
To: Board of Autruistic Inc.
Subject: Memorandum on setting up of a Project Management Team.

Greetings Sir/Madam,
This memorandum is proposed to present the project process and plan for the development of
company’s new product “Altru Drive”, which is cloud storage and sharing platform. As a project
manager, I am setting up a Project Management Team who will be responsible for initiation and
completion of the project.
Altruistic Inc. previously had a core product line for Email Management. Now the company is
planning to extend their product line to increase their influence in the market. They are
integrating new product “Altru Drive” for file storage in their current core product line. Using
this product users will be provided with their own cloud storage space. With it they will be able
to create folders, upload files, and also share them among other users. The users will also have
multiple options to view the items, search the items and also filter them by name, date, size and
type. With these options they also have manual and automatic backup features based on the
configuration. After analyzing the project, Agile approach is the suitable approach for this
project. DSDM formally known as Dynamic System Development Method is an agile software
development methodology. After the critical analysis of different agile development
methodologies, DSDM was chosen as the development methodologies for this project. DSDM
will be used from initiation to completion of this project. I am confident that DSDM
methodology will deliver the product of quality. In addition, standardized version of PRINCE2
standards are used to manage the project, identify the management team and delegate positions
in the team.
As a project manager, I must ensure that every partner is in the circle about the project’s
advancement and consulted when needed. The communication should be done face to face
conversation rather than formal documentation. That’s why we should use informal
communication mechanism. The informal communication should be done with daily standups,
meeting, facilitated workshop and video calls in the various development center. The tool like
RACI matrix will be used to utilized to recognize the person in control of a specific part of the
work.
To complete the project on time, we will break down the project into multiple milestones which
are time-boxed in 4 weeks duration for incremental releases. This project will cost $100,000
which includes all the cost associated with the project.
Chapter 2: Methodologies
2.1 Software Development Approaches
Software Development Approach refers to the methodology used to design and execute a
task advancement so that even an exceptionally complex project is separated into littler parts
which are difficult to appreciate, impart and complete within the given time span. Depending on
the idea of the task and the necessities of the project, we can have various kinds of software
development methodologies. The most widely recognized methodologies are Traditional and
Agile.
Despite the fact that both these methodologies have positives and negatives, settling on the
correct decision plays a crucial role while beginning a new project. The main points to consider
while picking right development methodology are as following:
a. Business Need: Effect of actualizing determined necessities, on clients' business.
b. Client’s Perception: Client point of view of business impact.
c. Project Timeframe: Characterized time span for the constant execution of the activities.
The traditional and agile approaches is the sequence of project phases, requirements gathering,
planning, design, development and testing. The traditional methodology has sequence of project
phases in linear. On the other hand, the agile methodology has iterative. In the following picture
the differences between traditional and agile methodologies:

(KPI Partners, 2018)

Traditional methodologies are plan driven in which work starts with the elicitation and
documentation of a total arrangement of prerequisites, trailed by structural and high-level
structure advancement and examination. Because of these heavy aspects, this approach became
to be known as heavyweight. A few specialists discovered this process centric view to
programming disappointing and poses challenges when change rates are still moderately low.
Subsequently, a few advisors have independently evolved techniques and practices to embrace
and respond to the unavoidable change they were encountering. These methodologies are
dependent on iterative improvements, a procedure that was presented in 1975 and that has gotten
known as agile methodologies. The name “agile” came about in 2001, when seventeen
methodologists held a meeting to discuss future trends in software development. They saw that
their techniques shared numerous qualities practically speaking so they chose to name these
processes agile, which means it is both light and adequate. In result to this gathering, the “Agile
Alliance” and its proclamation for agile programming advancement rose. Agile exposes
organizational dysfunction. In contrast to traditional approach, agile approach grasp iteration
instead of phases. Agile utilize short iterative cycles, little/short deliveries, straightforward plan,
refactoring nonstop integration and depend on tacit information inside a group instead of
documentation.
The agile methods claim to place more emphasis on people, interaction, working software,
customer collaboration, and change, rather than on processes, tools, contracts and plans. (M.A.
Awad, 2005)
Table 1: Comparison between Agile and Traditional Software Development Methodologies (M.A. Awad, 2005)

AGILE METHODS TRADITIONAL

METHODS
APPROACH Adaptive Predictive
SUCCESS Business Value Confrontation to plan
MANAGEMENT
PROJECT SIZE Small Large
MANAGEMENT STYLE Decentralized Autocratic
PERSPECTIVE TO Change Adaptability Change Sustainability
CHANGE
CULTURE Leadership-Collaboration Command-Control
DOCUMENTATION Low Heavy
EMPHASIS People-Oriented Process-Oriented
CYCLES Numerous Limited
DOMAIN Unpredictable Predictable
UPFRONT PLANNING Minimal Comprehensive
ROI Early in project End of project
TEAM SIZE Small / Creative Large

The focal values honored by the agilest are presented in the following which is now known as
Agile Manifesto:
 “We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.”
Since Agile approach require consistent joint effort with clients, utilizing their info and
input at different checkpoints during every iterative cycle, the nature of the final result is higher
and as wanted. Agile methods spotlight on esteem delivery instead of completion of the product
which permits us to test the center feature of the product quicker and take the item to the market
quicker and with higher certainty. Since the cycles are short and iterative, they give the essential
adaptability and speed to adjust to changes in necessities through consistent criticism from the
partners. Therefore, Agile method will be used for the development of Altru Drive.
2.2. Methodologies

Methodology is a set of process, practices and procedures used to complete a project.

Software development methodology is a way of managing a software project which focus on
area as follows: Software Requirements, Software Design, Software Construction, Software
Testing, and Software Maintenance. (IEEE Computer Society, 2014)

We have handful of Agile software development methodologies to choose from such as

Kanban, Dynamic System Development Method, Scrum, Adaptive System Development,
Extreme Programming, etc. I have selected two among these for the purpose of this project and I
will be briefing why one was selected with 7 points in favor of it and why the other was rejected
with 4 points against it. The two methodologies are:

a. Kanban
b. Dynamic System Development Method (DSDM)
2.2.1 Kanban
According to Atlassian, Kanban is a popular framework used to implement agile software
development. It requires real-time communication of capacity and full transparency of work.
Work items are represented visually on a Kanban board, allowing team members to see the state
of every piece of work at any time.
In the historical background of how Kanban appeared, it very well may be followed to
over 70 years back in time when Toyota started upgrading is designing process dependent on a
similar model that general stores were utilizing to stock their racks. Grocery stores keep stock
that is sufficiently only to satisfy the needs of the buyer along these lines permitting them to
offer more assortment which despite everything being exceptionally productive in stock
administration. Toyota applied the equivalent to its vehicle creation lines with an expectation that
it will yield better effectiveness by coordinating utilization of materials and stock degrees of
materials. To do this, the workers would pass a card, or a "Kanban", between the groups. At
whatever point a load of materials being utilized would be drained, the group would send the list
or Kanban to the distribution center portraying the specific amount of stock required. The
distribution center would then prepare the specific stock to send to production and furthermore
pass a list to provider which would then do likewise and transport to the stockroom. This
permitted Toyota to decrease the expense of stock enormously and furthermore clear route for
the JIT (Just In Time) producing process as we probably are aware today. Kanban works on the
following set of practices:
a. Limit work in progress
b. Pull new work from queue only when something is finished to enhance the flow
c. Visualize the workflow
Kanban fundamentally makes any association lean and mean by diminishing the odds of
suffocating because of abuse of assets or overburden of assets request. Kanban essentially works
with cards and boards. A card is a work where as a board is the state the work as of now is in.
There is a settled upon limit in number of cards there can be in work in progress load up at once
and permits pulling a card to a board as long as the limit isn't reached.
 Figure 1 : A demo of Kanban Board (Non-Electronic) (Hygger.io, 2020)

2.2.2 Dynamic System Development Method (DSDM)

DSDM is an Agile method that focuses on the full project lifecycle, DSDM (formally known as
Dynamic System Development Method) was created in 1994, after project managers using RAD
(Rapid Application Development) sought more governance and discipline to this new iterative
way of working. The key idea behind DSDM is to fix time and assets, and afterward alter the
measure of usefulness appropriately instead of fixing the measure of usefulness in an project, and
afterward modifying time and assets to arrive at that usefulness.
DSDM’s success is due to the philosophy “that any project must be aligned to clearly defined
strategic goals and focus upon early delivery of real benefits to the business.” Supporting this
philosophy with the eight principles allows teams to maintain focus and achieve project goals.
The eight principles of DSDM are:
1. Focus on the business need: Deliver what the business needs when it needs it.
2. Deliver on time: Plan timeboxes in advance and set the timeframes.
3. Collaborate: Cooperate and commit with shared ownership in project completion.
 4. Never compromise quality: Make the solution “good enough” by initiating tests early
and continuously.
5. Build incrementally from the firm foundations: Build confidence and take early
feedback.
6. Develop iteratively: Accept that work is not always right the first time and make sure the
timeboxes facilitate changes.
7. Communicate continuously and clearly: Use workshops, daily standups, modeling,
prototyping, presentations and encourage informal face-to-face communication.
8. Demonstrate control: Constantly evaluate the project viability based on business
objectives.

The DSDM system comprises of three consecutive phases, in particular the pre-project,
project life-cycle and post-project phase. The project period of DSDM is the most detailed of the
three stages. The project life-cycle phase comprises of 5 phases that form an iterative bit by bit
approach in building up an Information System.
 Phase 1: The Pre-Project
In the pre-project phase applicant projects are distinguished, project funding is
acknowledged and project duty is guaranteed. Taking care of these issues at a beginning
phase stays away from issues at later phases of the project.
 Phase 2,3,4,5,6: The Project life-cycle
The Project life-cycle comprises of 5 phases a project should experience to make an
Information System. The initial two phases, the Feasibility Study and Business Study are
successive stages that supplement to one another. After these stages have been finished up,
the system is developed iteratively and steadily in the Functional Model Iteration, Design and
Build Iteration and Implementation stages. The five stages are:
1. Feasibility Study
2. Business Study
3. Functional Model Iteration
4. Design and Build Iteration
5. Implementation
 Phase 7: Post-project
The post-project stage guarantees the system working adequately and productively. This
is acknowledged by maintenance, improvements and fixes as per DSDM standards. The
maintenance can be seen as proceeding with improvement dependent on the iterative and
steady nature of DSDM. Rather than completing the project in one cycle normally the task
can come back to the previous stages or stages with the goal that the previous step and the
deliverable items can be refined.
 Figure 2 : The 7 Phases of DSDM

The Core Techniques used in DSDM are:

 Timeboxing
 MoSCoW
 Prototyping
 Testing
 Workshop
 Modeling
 Configuration Management
 There are three levels or job classifications for arranging the jobs inside DSDM. Those
are the Project Level, the Solution Development Team, and the Support related roles. The
essential Project Team is contained inside the Project Level and the Solution Development
Team.

1. Project Level

The Project Level roles are concerned about coordinating and overseeing parts of the task
inside their specialty or region. Roles in the Project Level would be liable for connecting
with partners and giving venture administration. They give the required vision of the task and
work to guarantee that the vision is followed.

2. Solution Development Team

The Solution Development Team (SDT) is answerable for carrying life to the vision.
They cooperate cooperatively to fabricate the arranged item for the task. As much as possible
be controlled, individuals appointed to these jobs ought not be changed out or replaced. The
objective is to make a stable SDT that takes responsibility for work and region of obligation.

3. Supporting Roles

Supporting Roles provide project direction varying. They may uphold numerous tasks or
have different functions in the association. Their work in a project is centered around
exhorting or supporting the Solution Development Team in their specialization region.
Figure 3 : The DSDM Team Model (Agile Business Consortium, 2019)
2.3 Selection of DSDM
Among the two referenced Software Development Methodologies, I have concluded that DSDM
is the correct decision for this project for which the reason is as followed:
Explanation 1
Case The new product will be integrated with existing email management system.
Therefore, I need to provide time estimate to the marketing team so they can
plan things ahead.
Attribute Estimating the time of completion
Rationale DSDM locks in the time and makes sure the project does not extend the given
timeframe. The initial phases are dedicated for the same.

Explanation 2
Case “Altru Drive” should be modular so that we can add new modules in the future
to extend its capabilities.
Attribute Incremental Development
Rationale DSDM creates timeboxes which represent a core functional addon. Using
timeboxes, we can not only deliver incrementally, but also plan future updates
in the same fashion.

Explanation 3
Case “Altru Drive” will also be used internally for file management and sharing so
their feedback is crucial to the end result
Attribute Including the internal stakeholders into the project
Rationale DSDM promotes collaboration through multiple techniques and makes sure
that the internal stakeholders are always in the loop. The feedback from the
internal stakeholders are valuable and therefore well taken care of in DSDM.

Explanation 4
Case “Altru Drive” will add a new product link to our existing product offering and
must add value to the company.
Attribute Making sure that the product adds significant value to the company.
Rationale DSDM is business-oriented and focuses on business needs and building what
adds value to the business.

Explanation 5
Case The quality of the product will matter a lot as it can take us into new heights,
or drag the company down along with the core product. Therefore, quality
cannot be compromised at all. Additionally, this involves saving private
information of the end users, quality is even bigger concern.
Attribute Ensuring Quality
Rationale DSDM does not allow any tolerance in quality of output. Communication and
testing happen throughout the project process ensuring highest quality of
 product as the output.

Explanation 6
Case We are a multinational company with diverse team located across the globe.
Therefore, a very neat and clear role descriptions are required so that there is
no conflict across the company regarding the project development or outcome.
Attribute Easy to understand and clear roles
Rationale DSDM assigns clear roles to each involved in the project, thereby avoiding
any conflict between the team members or any stakeholder of the project.

Explanation 7
Case This product will have a host of features, all of which might not be equally
important. Therefore, we need to make sure the features which deliver the
highest value are developed, tested and deployed first.
Attribute Quick Value Delivery
Rationale DSDM uses MoSCoW prioritization technique to ensure that the initial
timeboxes include features that are of highest priority, or in other words, that
deliver the highest value.

2.4 Rejection of Kanban

As DSDM was chosen dependent on the previously mentioned justification, Kanban was
dismissed dependent on the accompanying reason:
Justification 1
Case This project is vital to the center product just as going into new market in the
ideal time. Thusly, we need extremely away from of the task time span so
everything including reconciliation can be prepared of it.
Attribute Estimating timeframe of the project
Rationale Kanban does not have any method to estimate timeframe. Instead, it only
focusses on getting things done one after another on need basis.

Justification 2
Case This project will impact the company’s value proposition as well the
company’s value in the market by large. The company’s vision should come
first.
Attribute Putting Company’s vision first
Rationale Kanban does not focus into business objectives, but mostly on tasks. Though
these tasks will ultimately impact the business, the business side is often
ignored in Kanban therefore it is not the best method for us.

Justification 3
Case We are a multinational company with diverse team located across the globe.
 Therefore, a very neat and clear role descriptions are required so that there is
no conflict across the company regarding the project development or outcome.
Attribute Easy to understand and clear roles
Rationale Kanban allows loose roles which is better suitable for smaller team only, and
not for a large MNC like ours where every role must be clearly defined.
Kanban can create conflicts as roles and responsibilities are not clearly defined
and therefore not good for this project or for us.

Justification 4
Case This project will not only cost a lot in development, but will be very costly to
maintain and scale. We need to be sure of everything before we jump into it to
avoid the risk of massive failure.
Attribute Feasibility Study
Rationale Kanban focusses on boards and tasks and the planning in Kanban involves
mostly determining attributes related to the boards. This does not serve our
purpose as we need a lot of feasibility study and business study before we
begin the project. Therefore, Kanban is not suitable for us in this regard.

2.5 Conclusion
Due to DSDM's Rapid Application Development (RAD) approach to software
development, we will have the option to accomplish the objective inside the given brief
timeframe outline for this venture. Notwithstanding being a major project, we need to prepare it
for market by the beginning of one year from now without settling on the nature of output. Along
these lines, we have picked this RAD approach whose iterative and steady methodology
accentuates ceaseless client/customer association, consequently yielding an attractive result.
Since the dynamic force is with the groups chipping away at it and clients are effectively
associated with the cycle, the enabled groups are extremely gainful and proficient and
consequently can meet the task prerequisites true to form. With DSDM, we will have the option
to accomplish a working stage in exceptionally brief timeframe and give us plentiful time for
arranging and propelling the product in the market.
Thusly, I believe, my determined choice to utilize DSDM for this project will yield us the
ideal output and revive our opportunity to showcase for the product.
Chapter 3: RACI Matrix
3.1 RACI Matrix on Process Level
Below is the RACI Matrix that maps the PRINCE2 processes with the project roles:

W
T
B o
e
u r
c
T B s k
h
ec S us i s
B B n
hn P B ol S in n h
usi usi T i
ica roj usi uti ol es e o
ne ne ea c
l ect ne on uti s s p
RO ss ss m a Agile
Co M ss De on A s F
LES Sp Vis Le l Coach
or an An ve Te m A a
on io ad A
di ag aly lo st ba d c
so na er d
na er st pe er ss v il
r ry v
to r ad i it
i
r or s a
s
o t
o
r o
r
r

Solution Development
Process   Project Level  Support Level
Level

Starting up a Project (SU)   R C C I C       C        

Directing a Project (DU)   R R I                    

Initiating a Project (IP)   R C C R C C I I I C C    

R/
Controlling a Stage   C C C C R I I C C C    
A

R/
Managing Product Delivery   I I C I C R R   C C C C
A

R/
Managing a Stage Boundary (SB)   I I     R              
A

Closing a Project (CP)   A C I R   I I I   I I    

Figure 4: RACI Matrix on Process Level

Legend:
R Responsible Assigned to complete the task or deliverable.

A Accountable Has final decision-making authority and accountability for completion. Only 1 per task.

An adviser, stakeholder, or subject matter expert who is consulted before a decision

C Consulted
or action.
 I Informed Must be informed after a decision or action.

The seven processes in PRINCE2 are described below as per the official documentation:
1. Directing a Project:
Directing a Project runs from the beginning up of the project until its conclusion. This
cycle is focused on the Project Board. The Project Board oversees and screens by means of
reports and controls through various choice focuses.
The business support is answerable for guiding the project from begin to end while other
project board individuals are counseled and educated alongside the business investigator and
the business minister.
2. Starting up a Project:
This is the principal cycle in PRINCE2. It is a pre-project measure, intended to guarantee
that the pre-imperatives for starting the project are set up.

The cycle expects the presence of a Project Mandate which characterizes in significant
level terms the explanation behind the project and what result is looked for. Firing up a
Project ought to be short.

The work of the process is built around the production of three elements:

 Ensuring that the information required for the project team is available
 Designing and appointing the Project Management Team
 Creating the Initiation Stage Plan.

This pre-project measure is driven by the business support and business visionary in making
the project order while the specialized organizer is educated regarding it.

3. Initiating a Project:
The objectives of Initiating a Project are to:

 Agree whether or not there is sufficient justification to proceed with the project
 Establish a stable management basis on which to proceed
 Document and confirm that an acceptable Business Case exists for the project
 Ensure a firm and accepted Foundation to the project prior to commencement of the work
 Agree to the commitment of resources for the first stage of the project
 Enable and encourage the Project Board to take ownership of the project
 Provide the baseline for the decision-making processes required during the project's life
 Ensure that the investment of time and effort required by the project is made wisely,
taking account of the risks to the project.

The business support is answerable for starting the project of which guides and organizers are
counseled for and arrangement group educated about.

4. Controlling a Stage:

This cycle depicts the observing and control exercises of the Project Manager engaged
with guaranteeing that a phase remains on course and responds to startling occasions. The
cycle shapes the center of the Project Manager's exertion on the project, being the cycle,
which handles everyday administration of the project.
Throughout a stage there will be a cycle consisting of:

 Authorizing work to be done

 Gathering progress information about that work
 Watching for changes
 Reviewing the situation
 Reporting
 Taking any necessary corrective action.

This process covers these activities, together with the on-going work of risk management and
change control.

The project director is responsible to ensure that the project is on target and doesn't go astray
based on what is arranged, and that the arrangement group comprehend their work
appropriately. The project board and different business centered colleagues are counseled by
the project director for this.

5. Managing Product Delivery:

The objective of this process is to ensure that planned products are created and delivered by:

 Making certain that work on products allocated to the team is effectively authorized and
agreed accepting and checking Work Packages
 Ensuring that work conforms to the requirements of interfaces identified in the Work
Package
 Ensuring that the work is done
 Assessing work progress and forecasts regularly
 Ensuring that completed products meet quality criteria
 Obtaining approval for the completed products.

The group head of the arrangements group guarantees that the product is conveyed as
arranged in past stages. As we are utilizing DSDM Agile Approach, coordinated mentor and
workshop facilitator are effectively counseled all through this cycle including the consultants.
The specialized facilitator and the business expert assistance the group chief into conveying
the products by effectively imparting all through the cycle.

6. Managing Stage Boundaries:

This cycle furnishes the Project Board with key choice focuses on whether to proceed with
the project or not. The objectives of the process are to:

 Assure the Project Board that all deliverables planned in the current Stage Plan have been
completed as defined
 Provide the information needed for the Project Board to assess the continuing viability of
the project
 Provide the Project Board with information needed to approve the current stage's
completion and authorize the start of the next stage, together with its delegated tolerance
level
 Record any measurements or lessons which can help later stages of this project and/or
other projects.

The project director in responsible to advise the project board on the presentation and
assessment of the project and the arrangements group.

7. Closing a Project:

The reason for this cycle is to execute a controlled near the project. The cycle covers the
Project Manager's work to wrap up the project either at its end or at untimely close. The
majority of the work is to plan contribution to the Project Board to acquire its affirmation that
the project may close.
The objectives of Closing a Project are therefore to:
  Check the extent to which the objectives or aims set out in the Project Initiation
Document (PID) have been met
 Confirm the extent of the fulfilment of the Project Initiation Document (PID) and the
Customer's satisfaction with the deliverables
 Obtain formal acceptance of the deliverables
 Ensure to what extent all expected products have been handed over and accepted by the
Customer
 Confirm that maintenance and operation arrangements are in place (where appropriate)
 Make any recommendations for follow-on actions
 Capture lessons resulting from the project and complete the Lessons Learned Report
 Prepare an End Project Report
 Notify the host organization of the intention to disband the project organization and
resources.

The business support wraps up the project educated the arrangements and backing group
dependent on the contribution from the project supervisor. The business visionary is
counseled by the business support before considering it a wrap.

3.2 RACI Matrix on Activity Level

Below is the RACI Matrix that maps the activities in DSDM with the project roles:
Te
Bu W
Bu ch So
Bu si Te or
si ni lu So Bu
Bu Pr si Te ne ch ks
ne ca tio lu si Ag
sin oje ne a ss ni ho
R ss l n tio ne ile
ess ct ss m A ca p
OL Vi Co De n ss Co
Sp Ma An Le m l Fa
ES si or ve Te Ad ac
on na al ad ba Ad cil
on di lo st vis h
sor ger ys er ss vis ita
ar na pe er or
t ad or to
y to r
or r
r

Solution Development
Activities   Project Level Support Level
Level

Pre-Project                            

R/
The Pre-Project Phase     C R                
A

Project Life-Cycle                            

Feasibility Study   A/ C C R R i i I C C C    
C
 C/
Business Study   R R C A I     C        
R

Functional Model
    C R A I R R R       C C
Iteration

Design and Build Iteration       R A   R R R       C C

I/
Implementation   A C R C C R R R C C    
C

Post-Project                            

The Post-Project Phase   A R     R       C   C    

Figure 5: RACI Matrix on Activities Level

Legend:
Responsibl
R Assigned to complete the task or deliverable.
e

Accountab
A Has final decision-making authority and accountability for completion. Only 1 per task.
le

An adviser, stakeholder, or subject matter expert who is consulted before a decision or

C Consulted
action.

I Informed Must be informed after a decision or action.

The seven phases or activities in DSDM are discussed in brief below:

1. Pre-project Phase:
In the stage step of DSDM, we make sure everyone is involved in the project and fully
aware of the project objectives and goals. Here, we conceptualize the project and decide to
begin the project.
Business Sponsor is responsible for the production of TOR in meeting with Technical
Coordinator and Project Manager who is liable for the making of TOR.
2. Feasibility Phase:
In this stage, we make sense of how to begin the project by doing specialized,
monetary and workforce investigation of the project. We additionally recognize the
imperatives restricting project conveyance and distinguish basic issues influencing time and
assets. In the event that we make sense of that the project isn't possible enough, we can even
drop the project at this stage.
 Here pretty much every part is either counseled or educated and the Project Manager
and the Business Analyst are dependable to set up the practicality study record. The Business
support should ensure the investigation is finished.
3. Business study Phase:
In this stage, we discuss the business aspects of the project. A few questions that we raise
and discuss in this stage are:
 Who are the participants?
 Is the project sensible from business point of view?
 Will it yield profit, and if so, when?
 What is the most suitable work plan?
 What are the resources required and associated costs in development?
 What tools and technologies will be required for building and deployment?
Business Analyst is responsible to ensure that the business study is done appropriately
while the Business Sponsor, Business Visionary and the Project Manager are dependable in
doing the examination. Business Ambassador and Project Manager are effectively counseled
and the Team chief is educated regarding the subtleties.
4. Functional Model Iteration:
In this stage, we examine, choose and organize all the specialized prerequisites of the
project. We assemble a useful model and afterward begin demonstrating it gradually, which is
then checked for quality and likelihood of progress by specialized specialists just as the end-
clients. The means associated with prototyping are researching the key functionalities,
arranging and booking groups and courses of events, making a model dependent on useful
prerequisites and evaluating the models for quality and further improvement.
The project supervisor needs to ensure that everything goes directly in here counseling
the help level individuals and the business visionary. The business examiner is kept on top of
it with respect to how the project is organized and gradual structures concluded dependent on
the input from Solution Development Team Members.
5. Design and Build Phase:
A product designed and implemented in iterations – Here in this stage
In this stage, we structure and convey the product in cycles, every one of will
comprise of choosing what capacities to include the emphasis, planning the capacities, coding
it, and afterward sending it. These cycles go in a cycle for every emphasis, and one usefulness
gets conveyed toward the finish of every cycle.
The project director takes the responsibility in driving the plan and fabricate stage by
preparing the arrangements group and with assistance from the help group. The specialized
organizer cooperates with the project administrator in driving the structure and assemble
stage.
6. Implementation phase:
In this stage, we send the finished result in full. Actually, we have just conveyed the
project in cycles as of now, while in this state, we get the entire project completely
operational and practical. Presently the project is prepared for market and we can dispatch it
after this stage. We additionally complete the documentations for the project including
preparing the clients who will utilize the product. This stage has three center goals – gather
(amass all endorsements and rules), audit (survey fulfillment and nature of each useful cycles
and send (train the clients and put the product in market).
The business support needs to ensure that the product we created is sent by the
arrangement's improvement group in dynamic counsel with practically all the individuals
from the project.
7. Post-project Phase:
This phase is all about periodic and ad-hoc maintenance of the system after it is
launched in the market.
The business examiner and the business visionary investigate the viably of the sent
product in discussion with the business diplomat and the counselor, while the business
support ensures that the criticism is appropriately gotten and the product is appropriately kept
up and refreshed even after the organization.
Chapter 4: Project Plan
4.1 Team Structure
The team hierarchy structure is shown in the figure below:

Figure 6: Team hierarchy structure of the project.

A brief comparison of organization roles and project roles is given below:

Name Organizational Role Project Role
Susanne Cruise Chairperson of the Board Business Sponsor
Samantha Richards CEO Business Visionary
Peter Bono CTO Business Visionary
James Seligman CFO
 Mandel Coleman CHRO
Agnes Robbins Director of Sales & Marketing
Martin Peron Director of Project Management Technical Coordinator
Bob Thomas Director of Operations Business Analyst
Leila Solomon President - USA
Dinesh Chopra President - India
Ankita Raut President - Nepal
Rumesh Udash Project Manager Project Manager
Table 2: Organizational Roles of the Team Members

Aside based on what is referenced above, every region has their own administration and
engineering group. The engineering group includes all specialized roles at Solutions
Development Level and Support Level. The supervisory team involves jobs generally at the
Project Level.
4.2 User Stories
S.N. USER STORY
1 As a user, I want to login to my account and upload files and folders.
2 As a user, I should be able to use my files and folders in a graphical user interface.
3 As a user, I want to share specific files or folders to specific users or share publicly.
4 As a user, I want to select which folder I am to upload my files or folders and name
them.
5 As a user, I want to delete my files but also be able to recover from trash.
6 As a user, I want to permanently delete my files which cannot be recovered.
7 As a user, I should receive notification when a file is shared to me.
8 As a user, I want to download files from my account or files which is shared to me.
9 As a user, I want to search within my files based on name, size, date.
10 As a user, I want to see the list of files that are recently uploaded and/or accessed.
11 As a user, I want to browse photos and videos separately.
12 As a user, I want to change the views of files and folders like I do in windows.
13 As a user, I want to set favorite items so I can easily access them.
14 As a user, I want to back up my files and recover from a backup.
15 As a user, I want a very fast file search which shows results in seconds.
16 As a product owner, I want to have the service up almost always with minimum or
no downtime.
17 As a Technical Manager, I want to distribute loads on servers equally so for
maximum operability during load time.
18 As a user, I want to be able to browse files on google drive using the same system.
Table 3: User Stories

4.3 Prioritization and Estimation

MoSCoW is a simple prioritizing technique used in DSDM which helps in understanding
and prioritizing the tasks. MoSCoW categorizes tasks in four prioritizes which is also the full
form of MoSCoW.
 Most-Have (Mo): The most vital things
 Should-Have (S): Things we consider as important, but not vital
  Could-Have (Co): The “nice-to-haves”
 Won’t Have (W): Things that provide little to no value and can be given up for now

Such prioritization is significant as we have to abbreviate our opportunity to-showcase

and complete the most pivotal parts first, at that point we will consistently possess energy for
things that are not fundamental until further notice or can be included later without trading off
the worth conveyance.

When we have organized the errands or client stories, every client story is given a story
point utilizing story point assessment procedure which is a cycle of allocating unitless incentive
to gauge the time that story to take to finish according to different stories. A story with story
point 1 is the quickest finishing story, and each other story are given story focuses according to
how much time the story takes contrasted with the story with story point 1. We ought to think
about story unpredictability, business esteem, chances, measure of work and conditions while
giving story highlight a story.

Below is the prioritization of the user-stories based on MoSCoW:

STORY
PRIORITY ID USER STORY POINTS
MOST- M01 As a user, I want to login to my account and upload 6
HAVE files and folders.
M02 As a user, I should be able to use my files and folders 9
in a graphical user interface.
M03 As a user, I want to share specific files or folders to 4
specific users or share publicly.
M04 As a user, I want to select which folder I am to upload 2
my files or folders and name them.
M05 As a user, I want to delete my files but also be able to 1
recover from trash.
M06 As a user, I want to permanently delete my files which 2
cannot be recovered.
SHOULD- S01 As a user, I should receive notification when a file is 3
HAVE shared to me.
S02 As a user, I want to download files from my account or 4
files which is shared to me.
S03 As a user, I want to search within my files based on 5
name, size, date.
S04 As a user, I want to change the views of files and 10
folders like I do in windows (list, grid, detail).
S05 As a user, I want a very fast search which shows 10
results in seconds.
 COULD- C01 As a user, I want to browse photos and videos 10
HAVE separately
C02 As a user, I want to set favorite items so I can easily 5
access them.
C03 As a user, I want to see the list of files that are recently 5
uploaded and/or accessed.
C04 As a product owner, I want to have the service up 15
almost always with minimum or no downtime.
C05 As a Technical Manager, I want to distribute loads on 20
servers equally so for maximum operability during
load time.
WON’T W01 As a user, I want to back up my files and recover from 6
HAVE a backup.
W02 As a user, I want to be able to browse files on google 10
drive using the same system.

4.4 Timebox Planning

Timebox Planning or Timeboxing is one of the most critical practices in DSDM. It takes
after a great deal of achievements in customary project approaches or sprint in a Scrum Method.
Timebox basically alludes to the measure of work to be done in a given time span. Each task can
have shifting timebox dependent on the goal of the timebox. Timeboxing causes us accomplish
the goal or focus in time, indeed, before time so we possess energy for input circle and
impromptu fixes. A timebox can be anyplace between about fourteen days to about a month and
a half which is considers a decent timebox, be that as it may, there isn't exacting guideline in
least and limit of timebox.
Timebox planning has following benefits:
 On-time delivery of product
 Improved productivity due to prioritized timeboxes
 Better planning and communication among team members regarding track of work
 Reduced dependency on other teams for completion of a timebox

Based on our solution team size and duration of the project, I have decided to keep
timebox of 2 weeks which translates to 10 working days. For each timebox, I have decided to
keep roughly 20 story points worth of tasks.
The timeboxes for this project are given below:
ID MoSCoW Story Points
M01 Most-have 6
M02 Most-have 9
M03 Most-have 4
 M04 Most-have 2
Table 3:Timebox 1 Plan

Objective: Create a basic working product which allows user to create their account, login and
upload and share files and folders.

ID MoSCoW Story Points

M05 Most-have 1
M06 Most-have 2
S01 Should-have 3
S02 Should-have 4
S03 Should-have 10
S05 Should-have 5
Table 4:Timebox 2 Plan

Objective: Allow operations such as download and delete and also very fast searching of the
files.

ID MoSCoW Story Points

S04 Should-have 10
C01 Could-have 10
C03 Could-have 5
Table 5: Timebox 3 Plan

Objective: Allow quick viewing and sorting of file and folders including separate browser for
photos/videos.

ID MoSCoW Story Points

C02 Could-have 5
C04 Could-have 15
Table 6: Timebox 4 Plan

Objective: Allow better usability with favorites and also make sure optimum up-time of the
server.

ID MoSCoW Story Points

C05 Could-have 20
Table 7: Timebox 5 Plan

Objective: To load balance so that the load is equally distributed among the servers.
 ID MoSCoW Story Points
W01 Wont-have 10
W02 Wont-have 6
Table 8: Timebox 6 Plan

Objective: Allow users to create backups and restore from those backups and also allow directly
browsing google drive via our system.

4.5 Project Plan

The project plan is shown in the tabular format below based on our previous estimation of
project completion and our estimation of solution development size of 10 and weekly workdays
of 5.
# Activity Deliverables Start End Duratio Resources
n
1 Pre-Stage TOR 09-06-2020 09-10-2020 5 days
2 Project Life Multiple
Cycle
a. Feasibility Project 09-13-2020 09-24-2020 10 Business
Study viability Analyst,
Document Business
Sponsor
i. Technical 09-13-2020 09-15-2020 3
Feasibility
ii. Financial 09-16-2020 09-21-2020 4
Feasibility
iii. HR 09-22-2020 09-24-2020 3
Feasibility
b. Business Cost-Benefit 09-27-2020 10-01-2020 5 Business
Study Document Analyst,
Business
Visionary
i. Cost Analysis Cost Plan 09-17-2020 09-29-2020 3
ii. Benefit Profit Plan 09-30-2020 10-01-2020 2
Analysis
c. Functional Prototype 10-05-2020 10-16-2020 10 Project
Model Manager
Iteration
i. Prototyping First 10-05-2020 10-12-2020 6
Prototype
ii. Reviewing First Viable 10-13-2020 10-16-2020 4
Prototype
d. Design and MVP 10-19-2020 02-13-2021 90 Project
Build Manager
Iteration
2 Implementati System 02-16-2021 03-03-2021 15 Project
 on Deployment Manager,
Technical
Coordinat
or
3 Post-Project System 03-03-2021 - Technical
Maintenance Coordinat
or

Chapter 5: Project Brief

5.1 Project Definition
5.1.1 Background

Altruistic Inc is an enormous global organization working in USA, India, and Nepal with
the headquarter situated in USA. Because of the size of tasks and advancement required,
Altruistic Inc has disseminated building and supervisory group over all areas. The center product
of the organization is Email Management System, for which, presently, we are going to
manufacture another product 'Altru Drive" which will be incorporated into it for better
administration of documents by the clients. This new product won't permit better email the board
through document sharing, yet will remember a large group of highlights for its own as an
independent record the executives and sharing stage where clients and deal with their documents,
peruse them, search through it, share it, and do a large group of different choices which are
impractical with neighborhood record the executives interface.

5.1.2 Project Objective

The core objectives of the project are to complete the project and make the product
launch-ready within the given time and budget:
 To start the project on time (Sept 6, 2020) and complete on time (March 3, 2021)
 To create the launch-ready product within the budget of $100,000.
 To use agile approach in development so that the end product is in-line with the
expectations.
 To create a product that will integrate well with the current email management system
thereby boosting the usability of the core product as well
 To ensure high-availability of the system so that the users can safely browse and store
their data into the system
5.1.3 Desired Outcomes
The desired outcomes of the project are to create a full-featured file sharing system which
is easy to use and integrates fully with the current Email Management System. These outcomes
and be further listed as:
  To allow user to create their own profile and maintain their preference, history which can
be used to enhance user experience
 To allow users to graphically manage their files and folders and to selectively or public
share to others
 To allow users to have a proper multimedia experience through dedicated photo viewer
and video player on the web
5.1.4 Project Scope and Exclusions
The scope of the project incorporates improvement of a record sharing stage dependent
on the necessities and to send the framework with the end goal that it can work easily even at
high burden. This project understands the issue of simple record sharing framework that needs
all mainstream mail the executive's frameworks by incorporating document sharing and email the
board into one stage. This project will be utilized by business experts, yet in addition ordinary
end-clients who are continually progressing and need their records nearby at whatever point they
require it.
Project Exclusions:
This project, however, does not include all that a file sharing platform can or will
provide. Below is the list of features which does not fall into the scope of this project:
 File download using P2P as this is not a file sharing, but a file management platform
which also allows file sharing
 Public forum to share files will not be created where users can participate in file sharing
and file requesting
 Public video streaming which will not be available, but the user who owns the video can
login and play the video
 Third party integration API will not be a part of this project scope, but perhaps can be
planned for future upgrades
5.1.5 Constraints and Assumptions
This project will have constraints applied to it so that the resources and time are not
exceeded and well-managed within the given constraints. The constraints are applied to three
major aspects of the project – cost, time and scope:
 Cost: The project team must provide the deliverables without exceeded the total cost of
the project which is finalized to be $100,000. We have reached to this figure by
calculating the amount of time and work required for this project.
 Time: The project is set to begin on first of September 2020 and complete on last of
March 2021. The project is time-boxed so that the project can start and complete in the
given time constraint.
 Scope: The scope of the project as discussed earlier will remain as it is throughout the
project. If the scope is changed during the process, it will also impact the other two
constraints of the project.
The following assumptions have been made to plan the project:
  The team will follow DSDM approach to project development.
 The team will have access to all resources required for the project development.
 It is assumed that the servers required to host and manage the system will be available as
needed and as per the density of the users.
 It is assumed that we will have required tech and support needed for maintaining security
of the system.
 It is assumed that the board is willing to invest more in the server storage capacity if the
project scales as expected.
5.1.6 Project Tolerances
Tolerances are set on six aspects so that there’s headroom of self-organizing team to play
within the tolerance levels without having to escalate it to the higher authority which can cause a
blockade in the project progress. The five tolerance levels are:
 Cost: In DSDM approach, Cost is not variable and does not have any tolerance level. If
cost goes higher than set budget, it has to be escalated to higher management.
 Time: Just as cost, time is also not flexible in DSDM.
 Scope: We have some headroom to play with in terms of scope, therefore, we can adjust
some changes in the scope, but not by much.
 Quality: The project of this nature cannot tolerate any compromise in quality, and
therefore there is no tolerance in it.
 Benefit: There is small tolerance in terms of benefit and the higher management must be
consulted immediately if there is significant variation detected.
 Risk: Minor risk can be mitigated by the team itself, but if there is some unforeseen risk,
the higher management should be consulted without further delay so it can be mitigated
with better capacity and planning.
5.1.7 The User and Any Other Interested Parties
The project requires all the partners to be educated when the project starts, creates and
dispatches. The key partners inside the organization are the board, speculators, c-level agents,
chiefs, presidents, arrangements group. The partners outside the organization are the clients who
are as of now utilizing the email the board framework and the new clients we will focus for
document the executive's framework.
5.1.8 Interfaces
After the project is completed, the following adjustments need to be done so as to
accommodate the project:
 Website must be updated the include the new product line.
 The description of the mail management system should be updated everywhere to include
the new integration of file management system.
 The marketing team should start making campaigns for product launch and promotion.
 The Finance team should allocate additional budget in marketing the new product and
features.
5.2 Outline Business Case
5.2.1 Reason

Altruistic Inc is an enormous global organization working in USA, India, and Nepal with
the headquarter situated in USA. Because of the size of tasks and advancement required,
Altruistic Inc has disseminated building and supervisory group over all areas. The center product
of the organization is Email Management System, for which, presently, we are going to
manufacture another product 'Altru Drive" which will be incorporated into it for better
administration of documents by the clients. This new product won't permit better email the board
through document sharing, yet will remember a large group of highlights for its own as an
independent record the executives and sharing stage where clients and deal with their documents,
peruse them, search through it, share it, and do a large group of different choices which are
impractical with neighborhood record the executives interface.

File sharing is an issue to anybody, particularly when it's too huge. Messaging the record
isn't a simple choice as most email suppliers don't permit large connections. So, by what means
will anybody share large documents over the web? One of the most well-known practice is
utilizing an outsider record sharing stage, yet every one of them are enlarged with advertisements
and most exceedingly awful, hold up times! No one needs to hold up keeping the window open
and afterward confirming the manual human test just to download the mutual record. In this way,
in light of the clients' necessities, we understood a product that permitted simple document
offering that in completely coordinated to email the board framework was something all clients
were searching for, however didn't have any feasible choice to select in. To tackle this issue, we
concocted the possibility of "Altru Drive" which is an independent document the board
framework which will be coordinated with the current email the executive's framework that we
offer to our clients.

This product won't just put our email management system in front of the opposition, yet
in addition permit us to dive into the document the executive's scene with our interesting product
line that offer implanted email usefulness.

5.2.2 Benefits Expected

There are a host of benefits that Altruistic Inc can expect from this product:
 The company will include a new product in the line of offerings.
 The current email management system will be improved due to integration of file
management.
 The company will see a massive growth of gross users across the board.
 The company will gain competitive advantage in the mail management and file
management industry due to uniqueness of the product.
 The company can use the system internally for file management which reduces the
dependency on third-party technologies.
  The company’s PR will get a huge boost as it will be known among much larger mass
ultimately increasing the company’s valuation.
5.2.3 Risks
The risks associated with starting the project:
 We must begin working with an assumption that storage servers will be easily available
whenever we need to scale up.
 Despite having expertise in security domain of email, we still lack expertise in security
domain of file sharing and do not have hands-on experience on it.
 Due to fluctuating costs of computer hardware, the cost of storage can vary in the future
affecting the total cost of the project.
 File sharing consumes a lot of bandwidth which can be a major bottleneck even with
multiple servers working simultaneously.
5.2.4 Costs
This project is will be developed by a solution team of 10, which includes a pool of
developers, Server experts and testers. The monetary cost of the project is $100,000 whose detail
is given in the appendix.
5.2.5 Time
The project will begin on Sept 6, 2020 and complete on March 3, 2020, which is a total
of 6 months. We have timeboxed the project into 6 parts, so that we can have at least 6
incremental updates with tests to complete the project in due time. The detail of this is already
given in previous section.
5.3 Project Product Description
Quality Criteria:  The product should solve the market problem that we are
hoping to solve with the product.
 The product should fulfil the user stories and be in line with
the objectives.
Quality Tolerances:  The quality should not be compromised and should be
within the set tolerances.
Quality Method:  Requirements in form of user stories
 MoSCoW prioritization for priority setting
 Daily standups and face-to-face communications for better
collaboration
 Continuous testing and feedback
 Business Acceptance testing
Quality  Project manager
Responsibilities:  QA Team

5.4 Project Approach

The project approach has been broadly talked about in before sections; in any case, I will
brief the improvement collaboration technique here. The advancement group contains 10
engineers and analyzers, which are all from Nepal and will be working from the Nepal office as
full-time in-house designers and analyzers. The DevOps will deal with setting up workers
worldwide while the product designers will zero in on prototyping and building up the main
product.
As discussed earlier, DSDM will be used as the project management methodology in
agile approach which will give us aforementioned advantages to complete the project in given
timeframe and cost.
The Core Techniques used in DSDM will be:
 Timeboxing
 MoSCoW
 Prototyping
 Testing
 Workshop
 Modeling
 Configuration Management

5.5 Project Management Team Structure

This has been detailed in the project plan section of this document.

5.6 Role Descriptions

This has been detailed in the project plan section of this document.

Chapter 6: PRINCE2 and DSDM

6.1 PRINCE2
PRINCE2 stands for Project in Controlled Environment, which is the world’s most
widely-adopted project management method, used by people and organizations from wide-
ranging industries and sectors.
It is a flexible method that guides you through the essentials for managing successful
projects, regardless of type or scale. Built upon seven principles, themes and processes,
PRINCE2 can be tailored to meet your specific requirements. The PRINCE2 method comprises
four integrated elements of principles, themes, processes and the project environment.
 Figure 7: PRINCE2 Principles

These are the guiding requirements and good practices which determine whether the
project is genuinely being managed using PRINCE2. There are seven principles and unless all of
them are applied, it is not a PRINCE2 project.

The seven PRINCE2 principles are:

1. Continued business justification: there must be a justifiable reason to be running and managing
the project. If not, the project should be closed.
2. Learn from experience: PRINCE2 project teams should continually seek and draw on lessons
learned from previous work.
3. Defined roles and responsibilities: the PRINCE2 project team should have a clear organizational
structure and involve the right people in the right tasks.
4. Manage by stages: PRINCE2 projects should be planned, monitored and controlled on a stage-
by-stage basis.
5. Manage by exception: people working within the project should be given the right amount of
authority to effectively work within the environment.
6. Focus on products: PRINCE2 projects focus on the product definition, delivery and quality
requirements.
7. Tailor to suit the project environment: PRINCE2 must be tailored to suit the project’s
environment, size, complexity, importance, capability and risk.
 PRINCE2 processes describe the steps of the project lifecycle, from the initial idea to
project closure (and measurement of the benefits). Each process provides checklists of
recommended activities, related responsibilities and guidance about how to tailor to a specific
environment.

The seven PRINCE2 processes:

1. Starting up a project
2. Directing a project
3. Initiating a project
4. Controlling a stage
5. Managing product delivery 
6. Managing stage boundaries
7. Closing a project
 Figure 8: PRINCE2 Project Lifecycle

(Axelos, 2019)

6.2 DSDM

DSDM (Dynamic System Development Method) is an Agile method that focuses on the
full project lifecycle was created in mid 1990s as the RAD mangers saw growing need
governance and discipline to iterative way of working. DSDM provides very little tolerance in
time and resources, but provides flexibility in functionality based on the set time and resources,
then readjust the time and resources to attain that

DSDM’s success is due to the philosophy “that any project must be aligned to clearly
defined strategic goals and focus upon early delivery of real benefits to the business.” Supporting
this philosophy with the eight principles allows teams to maintain focus and achieve project
goals.

This has been discussed in details in the chapter 2.

6.3 Critical Comparison of PRINCE2 and DSDM

Despite PRINCE2 and DSDM being product-based methodologies to manage projects,

they have differences as well as similarities, allowing both to work together as integral part of
the project management process.
 Figure 9: PRINCE2 and DSDM Positioning

(DSDM Consortium, 2000)

6.3.1 Integration in Process Level

The definition and the management of stages is a project the executive's movement.
PRINCE2 ought to along these lines be the prevailing strategy, as it is a project the executive's
technique, proposed for a wide range of project, while DSDM is a quick application
advancement strategy. For an association utilizing PRINCE2 for IT, this guarantees shared trait
among DSDM and different kinds of projects. PRINCE2 commands at least two phases, of
which one must be the commencement. The all-out number of stages utilized is then a matter of
judgment for the project supervisory crew, for DSDM projects with respect to some other kind.
Starting:
The beginning phases of PRINCE2, Start Up and Initiation, cover with DSDM's
Feasibility Study and Business Study. The products in this manner require defense. The two
strategies have a significant control point after an underlying comprehension of the project has
been picked up:
 End of Initiation (with Project Initiation Document and Plan) for PRINCE2
  End of the Business Study (with Business Area Definition, System Architecture
Definition, and Outline Prototyping Plan) for DSDM.
Both are focuses at which a choice to continue must be affirmed, and the choice of
relinquishing project must be thought of. Be that as it may, the degree of investigation required
by the Business Study is a lot more noteworthy than in a PRINCE2 inception and takes us more
profound into the project. The Business Study includes the exertion of the full group, but for a
brief period, which probably won't be the situation in a PRINCE2 inception. The two strategies
likewise have a prior, less basic, control point that is some of the time precluded:
 The Start Up (Products: Project Brief and Approach) for PRINCE2
 The Feasibility Study (Products: Feasibility Report, optional Feasibility Prototype,
Outline Plan) for DSDM, which is sometimes combined with the Business Study.

These match intently. Nonetheless, a difficulty is that PRINCE2 suggests consolidating

Start Up and Initiation for littler projects. DSDM projects would often fall into this classification,
however a project probably won't be allowed to acquire the expense of a Business Study without
some prior control point.
Running:
PRINCE2 doesn't need the board stages to coordinate specialized ones. An administration
stage may comprise of various DSDM timeboxes. The quantity of stages required ought to be
controlled by adjusting the measure of the board control required over the project and its dangers
against the likely overhead of overseeing stage limits. The project the board overhead in
finishing a phase and beginning the following fluctuates from association to association. On the
off chance that the overhead in the association is generous, it may be shrewd to plan a phase to
an augmentation. On the off chance that stage finishing and beginning is anything but a
significant exercise, at that point a phase may be planned:
 To a phase (if all the functional model iteration is done before all the design and build
iteration), or
 To the development of a functional area (where the functional model iteration and the
design and build iteration are done in alternation).
DSDM Implementation is either simply a part of the increment (where this is treated as a
single stage) or may be treated as one or more stages in its own right.
Closing/Ending:
Toward the finish of the project, the PRINCE2 close down covers with the project survey
in the DSDM Implementation stage. Nonetheless, the project survey in DSDM is done in every
addition and consequently relates all the more near a PRINCE2 End Stage Assessment, of which
the last happens to end the project. The key is fitting the techniques to do what is required and no
more, since in DSDM steady acknowledgment has just occurred. During early reception of
DSDM, the likelihood of and requirement for exercises learned data is increased. To catch
exercises took in, a full PRINCE2 close down is suggested in all cases.
6.3.2 Integration in Roles
In any project, someone has to take responsibility for the following:
 Defining the business requirement
 Providing the budget
 Providing the user and development resource
 Authorizing change
 Defining standards and acceptance criteria
 Managing the project to a successful conclusion
 Signing off project deliverables
Contingent upon the size of the project, one or a few people may accept these obligations.
Both PRINCE2 and DSDM uphold a project the executives' structure in which there is a
numerous to numerous connections between the individual and the job, and there is an
immediate correspondence between a large number of the jobs they each characterize. Both
stress the significance of senior administration responsibility for the duration of the life of the
project. This area portrays how the functions in DSDM (worried about doing advancement) and
PRINCE2 (worried about dealing with the project) supplement one another. Allude to the DSDM
Manual for the full meaning of DSDM jobs. The following figure illustrates the complementary
nature of project roles in PRINCE2 and DSDM.
 Figure 10: PRINCE2 and DSDM Combined Project Structure

(DSDM Consortium, 2000)

Project Board:
PRINCE2 necessitates that a Project Board is selected to give generally speaking bearing
and the executives of the project. The Project Board isn't explicitly needed by DSDM, yet it sits
serenely inside the DSDM project system. The Project Board comprises of three jobs:
 Executive: The PRINCE2 Executive maps directly to the DSDM Executive Sponsor and
is ultimately accountable for the project to corporate and / or program management.
Throughout the project, the Executive “owns” the business case.
 Senior User: The PRINCE2 Senior User corresponds closely with the DSDM Visionary.
In smaller projects, this may be the same individual as the Executive Sponsor. The Senior
User is responsible for committing user resource to the project.
 Senior Supplier: This is a PRINCE2 role and is not present in DSDM. The Senior
Supplier represents the interests of those involved in building and deploying the products
of the project.
Project Manager:
In both PRINCE2 and DSDM, the Project Manager is liable for the effective conveyance
of the concurred products, to the concurred norm of value, on schedule and inside financial plan,
and equipped for conveying the advantages expressed in the PID. The Project Manager may
originate from IT or the client network, and reports to the Project Board. PRINCE2 centers
around the conventional Project Manager obligations. DSDM includes an integral accentuation:
 Empowering the project team
 Protecting the project team from outside interference
 Ensuring that the team can remain stable and focused throughout the project
 Managing user involvement in the project and ensuring users continue to be available
when needed.
Team Manager:
PRINCE2 characterizes this function with regards to bigger projects, wherein groups of
various aptitudes and information are required or where an outsider is accomplishing work. For a
littler project utilizing PRINCE2 and DSDM, the Team Manager job maps legitimately to the
DSDM Team Leader job. This individual is answerable for guaranteeing that the advancement
group meets its goals by conveying the necessary framework.
Project Support:
An association may build up a Project Support Office to offer regulatory help to the
Project Manager, either due to the volume of work or to aid the utilization of specific devices in
the project (for instance project the board or setup the executive's instruments). This could
incorporate giving the recorder and facilitator jobs required by DSDM projects.
Project Assurance:
PRINCE2 allocates project affirmation capacities to the Project Board individuals, and
every part satisfies this function from their own point of view. The Project Board may assign
project affirmation obligations to an autonomous Project Assurance Team (which may have been
set up to do project confirmation for any or all projects).
6.3.3 Integration in Deliverables
Products delivered as a feature of the PRINCE2 cycle are the executives and quality
products. They identify with the viable and productive administration and control of the project
and to project quality, individually. Most products inside DSDM are pro products. That is, they
either contain data identified with the framework or advancement the project is to convey or
characterize the prototyping procedures and techniques to be utilized. There are, nonetheless,
some DSDM products that are either totally the board products or contain project the executive's
areas, (for example, the framework plan and layout prototyping plan) and some DSDM quality
products, (for example, survey records and test records).
To maintain a strategic distance from duplication of exertion, the suggested approach is
that administration products ought to be the territory of PRINCE2 and that any administration
components inside DSDM products ought to be stripped out and remembered for the suitable
PRINCE2 product. So also, duplication of exertion in making the quality products ought to be
evaded.

Project Initiation Document (PID):

The production of the Project Initiation Document (PID) stays a key control point in the
project. The PID will consistently be delivered. It might contain the administration parts of the
business study if the investigation is led right now. In the event that the Business Study is
directed after project commencement, the PID may have the option to characterize draft stages,
since these will be affirmed as a major aspect of the Business Study. For this situation, the PID
should make a forward reference to the Outline Prototyping Plan, a product of the Business
Study.
Since the Feasibility Study brings about pure administration products – the Feasibility
Report and the Outline Plan – these archives will be subsumed into the PID. The Feasibility
Prototype (a discretionary aspect of the Feasibility Report) is definitely not an unadulterated
administration product and may not be a record. In that sense, it can't be subsumed into the PID,
yet could be referred to from it.
The PID should also address any DSDM specific management issues. For instance, the
following would normally be covered in the Feasibility Report and should now be included in
the PID:
 Preliminary indication of areas within scope which may be desirable but not essential
 The need for team empowerment
 Facilities that the development team will need
 Any safety-related or product liability issues
 Define tailoring of approach for the project
 Suitability Filter
Feasibility Report:
This DSDM report will not be produced separately, but will be included in the Project Initiation
Document.
Outline Plan:
The points covered in the DSDM Outline Plan should be contained within the PRINCE2 Project
and Quality Plan (and these documents may be part of the PID). Hence the Outline Plan is
subsumed into these PRINCE2 documents and will not exist as a separate document.
Business Area Definition:
This is a DSDM archive that covers both master and the executives perspectives.
Consequently, we suggest that this product ought to be made independently from PRINCE2
products, however that the administration angles ought to be separated and remembered for the
Project Initiation Document. In particular, these include:
 The section relating to benefits, risks, costs and impact.
  Acceptance criteria.
Outline Prototyping Plan:
The Outline Prototyping Plan is created in the Business Study in DSDM to characterize
the principle prototyping stages inside the project. While these don't liken straightforwardly to
PRINCE2 stages, they will presumably assist with characterizing the stages - something
ordinarily characterized inside the PRINCE2 Project Plan and the Project Initiation Document.
In the event that the Business Study is done simultaneously as the Project Initiation, at
that point the stages characterized by reference to the Outline Prototyping Plan can be
incorporated into the PID. On the off chance that the Business Study follows commencement, at
that point the stages characterized inside the PID and Project Plan will be draft, to be affirmed
following the Business Study. This model in certainty fits with both PRINCE2 and DSDM ways
of thinking on arranging, which perceive that arranging is iterative and, at any stage, just the
following stage is arranged in detail (albeit in general time-scales are arranged in advance).
The Outline Prototyping Plan will remain as a key document within DSDM. Some
aspects of it may be included in, or referenced from, the PRINCE2 Project Quality Plan.
Implementation Strategy:
This relates closely to a PRINCE2 Stage Plan and will be incorporated into the
appropriate one.
Development Risk Analysis Report:
PRINCE2 recommends that a danger investigation is attempted during the
commencement stage and beginning dangers contained inside the PID. The project at that point
keeps up a danger log, which the two screens and oversees known dangers and furthermore
records new dangers. These systems likely block the necessity for a different DSDM
Development Risk Analysis Report, despite the fact that the particular dangers with DSDM
projects must be considered.
Project Review Document:
The substance of the DSDM Project Review Document are contained inside a PRINCE2
End Stage Report. All things considered, the fruition of an addition (which is where the Project
Review Document is composed) will concur with the finish of a PRINCE2 stage. Along these
lines, the Project Review Document will most likely be subsumed into the End Stage Report.
The Quality Log and Prototype Review Records:
The PRINCE2 Quality Log, which records the solicitations to and results from quality
audits, is the undeniable spot to store the DSDM Prototype Review Records.
Appendix
S.N Description Unit Cost Months Cost ($)
1 Physical expenses
a. Rent 2000 6 12000$
b. Electricity 500 6 3000$
2 Personnel expenses
a. Senior Software 1500 6 36000$
Developer (X4)
b. Quality Assurance 500 4 4000$
Specialist
(X2)
Software 1000 6 12000$
Developer (X2)
c. UI/UX designer 1000 6 12000$
(X2)
3 Server Cost 1000 3 3000$
4 Mis Expenses 18000$
TOTAL 100,000$
References
Tools QA, n.d. DSDM: A Step-by-Step-Guide [2019]. [Online]
Available at: https://www.toolsqa.com/agile/dsdm-guide/
[Accessed 3 September 2020].

ILX Group, n.d. PRINCE2 Processes. [Online]

Available at: https://www.prince2.com/eur/prince2-processes
[Accessed 3 September 2020].

Joshua Render, n.d. DSDM Roles and Responsibilities. [Online]

Available at: https://agile-mercurial.com/2019/04/03/dsdm-project-management-roles-and-
responsibilities/
[Accessed 3 September 2020].

Select Business Solutions Inc, n.d. What is DSDM. [Online]

Available at: http://www.selectbs.com/process-maturity/what-is-dsdm
[Accessed 3 September 2020].

Invensis Learning Pvt Ltd., n.d. Principles, Themes, and Processes of PRINCE2 - Explained! [Online]
Available at: https://www.invensislearning.com/resources/prince2/principles-themes-and-
processes-of-prince2-explained
[Accessed 3 September 2020].
ILX Group, n.d. About PRINCE2. [Online]
Available at: https://www.prince2.com/eur/prince2-processes
[Accessed 3 September 2020].