Tempus Software Project Management SE603 Unit 2: Project Planning – 1/2 Egypt, 8.6.2015.

Tempus

Software Project Management SE603

Unit 2: Project Planning – 1/2

Egypt, 8.6.2015

2

Introduction

• Planning is the core element in the project management in any domain.

• In plans, you decide how to approach the objectives, satisfy client’s expectations, define deliverables, break down products into workable and smaller units, allocating resources and schedule activities.

• Plan types include short and long term while identifying and handling risks.

• A considerable portion of the people working in the software industry undermines the value of planning as it consumes time and efforts.

3

Evaluation

• 5~6 Assignments x 4~5• Project 15~20, what ?

• A1: Read chap 3 of Hughes (5ed) and solve all questions (up to 1,2,3 in section 3.13)

• Read and critique sample project, quality, scm and risk plans in the light of Step-Wise.

• 4 marks

4

Introduction

• However, without planning, they are flying blindly with no proactive action for any sudden changes.

• Besides, Failing to plan is a planning to fail.• so, it is off major concern to be aware of the best

patterns and practices in this area.• In this unit, a step by step planning framework

(STEP WISE), a complement to PRINCE.

5

Objectives

Identify differences between PMP, PRINCE and SCRUM

Investigating the WISE-STEP planning framework

6

Unit 2: List of topics

1.The Difference between PMP, PRINCE and Scrum2.STEP WISE Planning

2.0. Step 0: Initiation 2.1. Step 1: Defining Scope and Objectives2.2. Step 2: Understanding Client infrastructure2.3. Step 3: Features Analysis2.4. Step 4: Defining outputs2.5. Step 5: Effort Estimation 2.6. Step 6: Handling risks2.7 Step 7: Resources Allocation2.8. Step 8: Plans Review2.9. Steps 9 & 10: Plans Execution

1. Difference between PMP, PRINCE and Scrum (1/2)

7

In order to kick off any project, you should determine which management approach you should adopt to manage the activities of having your product complete.

In the world of the software projects, there are three major approaches used widely support project manager in planning and managing projects: PMP , PRINCE and SCRUM

1. PMP (Project Management Professional) [5, 2] • is a general project management standard based on best

practices from various industries. • However, PMP doesn’t list the steps required to have a

well managed project and considers only the project manager's role.


8

2. PRINCE (PRojects IN Controlled Environment) [5, 2, 9] • project management standards that were originally

sponsored by what is now the Office of Government Commerce (OGC) for use on British government ICT and business change projects.

• It is a general project management methodology that conveys in a step by step fashion what must be done, when and where by whom to have a well-managed project,

• However, PRINCE considers only a high level activities such as control and organization of a project, not the lower level activities such as scheduling.

• Step Wise covers only the planning stages of a project and not monitoring and controlling.


3. SCRUM [6] • It is an iterative and incremental agile methodology that

is most commonly used in software development. • SCRUM is different than PMP and PRINCE as it considers

the rapid change of the requirements and expectation of the customers asking for software solutions.

• Therefore, the development is done in the SCRUM in the form of short time interval iterations.

• In Each iteration, the customer is able to check the deliverables and confirm his interest to continue.

9

2. STEP WISE Planning

PRINCE is a step-by-step methodology for managing projects handling high level activities such as control and organization of a project. However, it lacks dealing with the lower level activities such as scheduling. To overcome this issue, STEP WISE methodology emerged to complement PRINCE. [1]

10

Step 0 Initiation

Step 1: Defining Scope and Objectives

Step 2: Understanding

Client infrastructureStep 3 Project Characteristics

Analysis

Step 4 Identifying deliverables

Step 5 Effort Estimation

Step 6 Handling risks

Step 7 Resources Allocation

Step 8 Plans Review

Step 9 Plans Execution

Step 10 Low-Level Planning

For Each activity

review

Lower leveldetail

Figure: STEP WISE Planning Steps [1]

2.0. Step 0: Initiation

• In this step, the key elements for starting the project are identified such as scope, financial streamlines and stakeholders [1].

• All initial information is documented in the project charter which confirms that this project worth to be undertaken.

• As the project charter is approved by everyone on the board rooms, the project becomes officially authorized.

• The items of the project charter could be [8]:1. Objectives and Deliverables 2. Target market and segmentation3. Stakeholders4. Scope of the project5. Constraints and Risks6. High level budget

11

2.0. Step 0: Initiation

Example: consider college “Brightmouth” has payroll processing carried out by a services company. The payroll services provided to the university is very expensive. Decision made to bring payroll ‘in-house’ by acquiring an ‘off-the-shelf’ application. The use of the off-the-shelf system will require a new, internal, payroll office to be set up. There will be a need to develop some software ‘add-ons’: one will take payroll data and combine it with time-table data to calculate the staff costs for each course run in the college.

13

2.1. Step 1: Defining Scope and Objectives

This step is the corner stone of all the subsequent steps. If the stakeholders did not conduct regular meetings put hands on objectives, deliverables and confirm the scope before the project being kick started, the project members will struggle throughout the course of the project.

it is about making sure that project stakeholders understand and confirm the scope of the project that includes goals, deliverables, tasks, costs and deadlines.

This step is divided into series of sub steps that try to spot the key elements of having successful project initiation. 14


1.1 Identify objectives and measures of effectiveness in meeting them

1.2 Establish a project authority1.3 Identify stakeholders1.4 Modify objectives in the light of stakeholder

analysis1.5 Establish methods of communication with all

parties

15

Step 1.1: Clarifying objectives and setting measures of effectiveness• Identifying the objectives is the key element of any

project. • Meeting these objectives is the success criteria to

evaluate the project. • It is not only meeting the time, budget and scope

constraints but also having the expectations of the client realized.

• To meet the expectations of the clients, the client should be engaged frequently to have an overview about the progress done so far.

I


16

Step 1.1: Clarifying objectives and setting measures of effectiveness• In these meetings the measures of effectiveness and

outstanding customer satisfaction could be depicted as the elements of the software quality. These elements could be categorized into 3 quality groups in the software industry domain: Product operation, Product revision and Product transition.


17

Step 1.1: Clarifying objectives and setting measures of effectiveness

Product operation quality factors [10]:• correctness – having user objectives satisfied• reliability – minimizing failure rate and maximizing

accuracy • efficiency – utilizing computer resources to the best of

the capability• integrity – keeping sensitive data secured• usability - cutting down effort and time needed to learn

and use


18

19

Product revision quality factors [10]:• maintainability – the ability to spot errors and fix them• testability - testing functions and ensuring they did the

purpose• flexibility – the ability to modify and tune

Product transition quality factors [10]:• portability – the ability to have the solution run on

different hardware/OS• reusability – the easiness of using existing components in

another systems or applications• interoperability – the effort needed to couple to another

system


20

Example: Continuing the previous example of Brightmouth college. The stakeholders of the payroll project have preliminary agreed on set of objectives:• Reducing time required to updating employee profiles and

responding to enquiries• Supporting managers with tools to analyze overtime and areas for

productivity improvements• Enabling senior management to have hands on decision support

toolsThe stakeholder have set certain measures of effectiveness:• integrity – As data of high value for the university, they like to have

the data secured and safely kept• maintainability – the stakeholder asked to find a way for reporting

bugs and fixing them


Step 1.2: Defining project authority This sub step is concerned with the person-in-charge or the group of executives-in-charge for managing the project, interacting with the stakeholders, advising strategic directions and steering the project members.

Example: Setting Brigitte as the project manager for the Brightmouth college payroll system.


21

Step 1.3: Identify stakeholders• The stakeholder is any individual, group, or organization

that has direct effect or being affected by the activities done in the project [9].

• Missing or underestimating a stakeholder in later stages might affect adversely the course of the project and that would cost too much to mitigate and even in case of recovery the customer satisfaction level might be low.


22

Step 1.3: Identify stakeholders

Continuing the example of Brightmouth college:In pursuit of identifying all possible stakeholders of the payroll system, Brigitte spotted to extra clients for the new system: the finance department and the personnel office.

A vice principal agrees to be official client, and monthly meetings are chaired by the VP and attended by Brigitte and the heads of finance and personnel. IT department manager and selected personal staff would be engaged.


23

Step 1.4: Modify objectives in the light of stakeholder analysis

• As stakeholders are actively involved in the project to make sure their objectives and expectation are met,

• They could change the project requirements or configurations by adding more features.

• These changes might result in creating additional risks. • The project team should balance the demands, and

maintain proactive communication with stakeholders in order to deliver a successful project.


24

Continuing the example of the college: the stakeholders added the extra features:• portability – as the staff might work from home using

their laptops with the possibility to run the system on different operating systems

• interoperability – the possibility of the system to be integrated and linked with many other systems is too high, so the stakeholders asked to consider this issue.


25

Step 1.5: Establish method of communication• To keep stakeholders informed with all updates running in

the projects, • formal communication methods should be established

such as emails. • In case an issue of conflict, the stakeholder could reply all

or to the person in charge to hold operation or call for meeting to discuss any change.

• Reply allowance period should be determined as well [9].


26

Step 1.5: Establish method of communication In the college example: Brigitte notified stakeholders that email is the formal way of communication while addressing the stakeholders in cc. Any changes will be notified through emails, in case of no reply for 5 working days, the change would be effective as no stakeholder refused the change.


27

2.2. Step 2: Understanding Client infrastructure

2.1 Establish relationship between project and

strategic planning

2.2 Identify installation standards and

procedures

2.3 Identify project team organization

28


Step 2.1: Determining the link between the project and strategic planning

• As customer considers injecting a new software system into the working environment, it is done for the purpose of satisfying a strategic objective [1].

• In this step the PM should identify the link between the new project and the existing portfolio of projects to make sure that current and successive IT projects are compatible with the planned project.

29


Step 2.1: Determining the link between the project and strategic planning

In the college example: while Brigette was investigating the college strategic plan which includes the enhancement of the administrative procedures, she identified that the payroll system would be implemented as a module in the ERP system to cover the college’s financial processing needs.

As the payroll system is an extension of an existing system, the hardware and software platforms upon which the application are to run are dictated.

30

31


Step 2.2: Determining standards and procedures for installation @ the client side• Entities developing software products should define their

development procedures and standards. • The standards could be related to change and

configuration management to make sure that changes are done effectively and efficiently ;

• or could be related to monitoring and controlling to collect statistics, track performance and take the corrective actions if needed.

• The procedures could be related to quality; where quality checks are set at each point of the project life cycle.

32


In the college example: Brigette set the following:• For change and configuration procedures: no change or

add for extra features without detailed specification• For control procedures: Stakeholders must approve

changes before the work is carried out. • Weekly Informal meetings with Brigette colleagues to

discuss progress and scrutinize details ; • Monthly meetings with the vice-principal - official boss,

and the heads of the finance and human resources sections to review progress in general terms.

• For quality procedures, each person in the group has to get someone else to check through their work when they finish a major task.

33

Step 2.3: Be aware of project team organizationThe organizational structure is about organizing activities of task allocation, coordination and supervision to achieve the organizational objectives. There are three well known organizational structures: Functional Organization, Matrix Organization and Projectized Organization [9].


34

Step 2.3: Be aware of project team organization• In functional organization, the entire organization

is organized as department such as sales / marketing / finance departments are managed by department heads.

• In case a project is about to kick start, a member from each department might join the the project under the command of the project manager.

• Technically speaking the staff of the project report to both the department heads and the project manager.


35

In Projectized organization, the entire organization is organized by projects. The full time project manager has the ultimate authority for selecting his staff and has direct input in their evaluations. In this case the project manager has the complete authority to call the resource of interest and guarantee his full dedication. The project coordination is done through the project manager [11].


36

• Matrix organization structure is a hybrid version of both functional and Projectized organization structures.

• In this structure, two command structures could be found: vertical and horizontal.

• An employee might be part of a functional department but he may also work on a project.

• This structure takes the benefits of both organization in a balanced way.


37

In the college example, Brigette has the ability to split her team into business analysts to collect and analyze system features; developers who would develop and integrate the payroll with the existing systems ; support staff that respond to employees enquiries in connection to how to use ; etc.


2.3. Step 3: Project Characteristics Analysis

• Once the major elements of the project such as scope, objectives, features and infrastructure are surveyed and documented, it is time to kick start the implementation.

• There is no typical way to implement a software product or service it all depends on the nature of the project.

• Consequently, the project manager would choose the best development methodology, the proper life cycle approach, the way of handling risks and estimating efforts.

39


• 3.1 Distinguish the project as either objective- or product-driven

• 3.2 Analyse other project characteristics• 3.3 Identify high-level project risks• 3.4 Take into account user requirements concerning

implementation• 3.5 Select general life-cycle approach• 3.6 Review overall resource estimates

40


This step digests the project nature either product or objective driven, spots risks that affect the outcome of the project and considers the client’s standards and procedures. This is done to carefully select the development methodology and the lifecycle approach while giving the project manager a better understanding on the current situation on the efforts estimation.

41


Step 3.1: Determine if the project is product or objective driven Project is classified as product driven, in case, a client asked to have a product to satisfy certain specifications where the client’s responsibility is adjusting the product to meet his objectives.

42


Step 3.1: Determine if the project is product or objective driven

On the other side, the project is classified as objective driven, in case, a client asked to develop a system to improve some service to the users.

The level of service provided is subject of an agreement rather than the specifications of the developed system.

In the case of the Brightmouth, the requested system is an example of product-driven project [3].

43

44


Step 3.2: Analyze non-functional requirements

It could be safety critical where malfunction could threaten human lives.

45


Step 3.3: Identify high level project risks • Risks are raised from the operational environment or due to

technicalities. • An example of the operational environment risks is the

resistance to change. • Some senior staff consider installing new system that absorbs

their knowledge and experience they gained along many years is a threat. This is because fresh candidates with the minimal time of experience could in short time act as seniors.

• An example of the technicalities risks, the backward compatibility with the existing systems as it requires extensive programming and customizations.

46


In the case of the Brightmouth college, Brigette might face a technical risk. She is worried about finding a ready-made product that responds to most requirements raised in the previous steps earlier.

In case the candidate product has less features than expected that implies intensive development might be involved.

Step 3.4: Considering user requirements regarding implementationSome clients have their own procedural requirements. That is more clear for some governments that require the use of certain software project life cycles such as waterfall method [9]


47

Step 3.5: Selecting the development methodology and the lifecycle approach• According to the configurations of the project and the

requirements of the clients driven from the previous steps, lifecycle approach and the development methodology would be selected.


48

Step 3.6: Reviewing Resource Estimates• Till this stage, scope and objectives should be revisited,

extra risks have been identified, development methodology and lifecycle approach were selected.

• This means efforts and resources required to implement the project should be roughly re-calculated considering and revising cost estimates and the team organization.


49

2.4. Step 4: Identifying Deliverables

As projects aim to achieve objectives through delivering outputs, many activities are considered to have these deliverables produced. In this step, deliverables are identified on screens, and the activities used to produce them are managed and planned. Planning the sequence and flow of activities is off major concern to fully and efficiently utilize project resources whether financial or human.

51


4.1 Identify and describe project products

(including quality criteria)

4.2 Document generic product flows

4.3 Recognize product instances

4.4 Produce ideal activity network

4.5 Modify ideal to take into account need for

stages and checkpoints

52


Step 4.1: Identifying Products • Defining deliverables from the early stage is important as

the client expects to have set of products or / and services that realize his objectives.

• Missing a deliverable means a major flow in digesting the documents produced on the early steps.

• On top of that, considering to add a missing deliverable in the mid course of the implementation has severe impact on the planning and integration.

53


Step 4.1: Identifying Products

• There are two types of deliverables, final-end and intermediates.

• For the final end, the client is handed a product or service by the end of the project that might include training manual and operating instructions.

• Intermediate or sub-product is used in the process of creating another deliverable.

54

In order to identify the project deliverables, Product Breakdown Structure (PBS) is developed and continuously refined until all deliverable are identified. It is breaking the grand product into sub products and the sub-products are broken into smaller sub-products [12, 13].

55


Project Products

System products

Module Products

Management Products

Module Design

Documents

Module Code

Integration Test Cases

Test integrated Software

Progress Reports

Overall Specification

According to PRINCE2 [7], the final products are attributed as the following:• Name• Purpose • Derivation (the other products from which it is

derived)• Composition• Form • Relevant standards;• Quality criteria for acceptance


In the college example, as Brigette is responsible for selecting the appropriate software and hardware for the payroll system, she is planning to draft an invitation to tender for the potential suppliers. In order to do so, she is trying to find out the elements needed to produce the invitation, therefore, she developed the PBS for this selection process. She broke down the products selection process into volume figures (the number of employees for whom records will have to be maintained), office layouts (the plans of the physical space for installing servers and equipments), the user requirements, the invitation to tender document and finally the list of potential suppliers (to send them the invitation). Then, she broke down the user requirements into existing system description (analysis of the current system), the user’s modified requirements (the extra features needed by the college) and finally the test cases (the cases needed to test the validity of the system). Brigette decided that the finance department is responsible for carrying out acceptance testing of the new payroll system.


58


Products selection for the payroll system

Office Layouts

Plan

User requirements

List of potential suppliers

Existing system Analysis

User’s modified requirements

Test Cases

Volume Figures

Invitation to tender

59


Step 4.2: Developing Product flow DiagramAs product is divided into sub-products and the sub-product could be divided into smaller sub-product. So this means that some sub products must be exist before others because of the dependency relations either between the descendant sub-products and the parent sub-one or between the sub-products in the same level [12, 13].


For example, if you are going to develop a software system according to the user requirements; firstly, you should collect the product specification. Secondly, developing the module design. Thirdly, Module coding. These products are dependent on each other. You could develop separately the test cases. These relationships are depicted in a Product Flow Diagram (PFD)

User requirements

System Specifications

Modules Design

Module Coding Integrated and

tested Software SystemIntegration

System Test cases

61


In connection to the college example with reference to the product breakdown structure, Product Flow Diagram (PFD) is created as shown below.

Existing System

Analysis

User requirement

s

Test Cases Generation

invitation to tender Draft

Potential Suppliers list

Office Layouts

Volume Figures

invitation to tender


Step 4.3: Recognizing product instancesIn step 4.2 example, for modules design, as the software system is naturally composed of multiple modules, so it is expected to have a design for each module. This means for the product “Module Design” multiple instances based on the number of modules. And the same for Product “Module Coding” as each module design needed to be coded, the instances of product “Module Coding” will be the same as the product “Module Design” as shown in the figure below.


Specify overall system

Design Module A

Design Module B

Code Module A

Code Module B

Test Integrated Software System

S S

Design integration test cases


Step 4.4: Developing Activity networkEach product is composed of activities to be produced. Even generating a product from another is a process composed of activities. Having identified the activities of each product in the PDF while highlighting the order of execution, the activity network is developed. This network is ideal as no resources constraints are considered. In the figure below, designer and developers are available for Modules A and B where these modules are developed in parallel. All activities are labeled as verbs on the contrary of the PDF that is labeled as nouns [14].


66

In connection to the college example, with reference to the PFD, the activity network is created as shown below.

Analyze Existing System

Obtain User requirements

Generate Test Cases

Draft invitation to tender

Survey Potential

Suppliers list

Plan Office Layouts

Calculate Volume Figures

Issue invitation to tender

S

E

Step 4.5: Injecting check points in the Activity Network• To ensure the quality of the products produced and to keep

controlling the project, checkpoints should be placed after a sequence of activities forming a mile stone.

• Check points are dummy activity with no duration. • Having passed these check point, it implies that the previous

activities behind the check point are complete properly.


67

Specify overall system

Design integration test cases Design

Module A

Design Module B

Code Module A

Code Module B

Test Integrated Software System

Chec

k po

int

S S

Summary

• The key to a successful project is planning

• PMP is a general project management standard based on best practices from various industries. However, PMP doesn’t list the steps required to have a well managed project and considers only the project manager's role

• PRINCE is a general project management methodology that conveys in a step by step fashion what must be done, when and where by whom to have a well-managed project, unlike PMP

• SCRUM is an iterative and incremental agile methodology that is most commonly used in software development

• STEP WISE methodology emerged to complement PRINCE

• STEP WISE PLANNING is composed on 10 steps

• Step 1: Defining Scope and Objectives; the corner stone of all the subsequent steps. it is about making sure that project stakeholders understand and confirm the scope of the project that includes goals, deliverables, tasks, costs and deadlines. 69

Summary

• Step 2: Understanding Client infrastructure. This step is about understanding the environment running at the customer side including the infrastructure that would host the software system, the compatibility of the new injected system with the ongoing systems and applications and the project team organization

• Step 3: Features Analysis. This step digests the project nature either product or objective driven, spots risks that affect the outcome of the project and considers the client’s standards and procedures. This is done to carefully select the development methodology and the lifecycle approach

• Step 4: Defining outputs. In this step, deliverables are identified on screens, and the activities used to produce them are managed and planned.

70

References 1. Hughes, R.T., The `step wise' planning approach to software projects; IEE Colloquium on

Project Management for Software Engineers, 19952. http://www.hilogic.com.my/PRINCE2-PMP-PMBOK-Comparison.html3. Agarwal, B. B.. Software engineering and testing / B.B. Agarwal, S.P. Tayal, M. Gupta. p. cm.

ISBN 978-1-934015-55-1 (hardcover). ISBN 978-0-7637-8302-0 (e).4. Hughes, B. and Cotterell, M., Software Project Management, McGraw-Hill, 5th ed., 2009.5. http://www.webgale.com/difference-between-pmp-prince2-and-scrumagile/6. http://www.mountaingoatsoftware.com/agile/scrum7. Office for Government Commerce. Best Management Practice – PRINCE2.8. http://en.wikipedia.org/wiki/Project_charter9. PMBOK 5th Edition10. http://www.cs.mun.ca/~mhatcher/3716/Lecture%20Slides/Week%2010/Project

%20Management.pdf11. http://pmstudycircle.com/2012/08/type-of-organization-structure/12. http://www.productbreakdownstructure.com13. http://www.liquidplanner.com/blog/product-based-plan/14. http://www.sixsigmadaily.com/the-activity-network-diagram/15. http://project-management-knowledge.com/definitions/b/bottom-up-estimating-technique/16. http://www.mindtools.com/pages/article/newPPM_03.htm

71

http://www.hilogic.com.my/PRINCE2-PMP-PMBOK-Comparison.html

http://www.hilogic.com.my/PRINCE2-PMP-PMBOK-Comparison.html

http://www.webgale.com/difference-between-pmp-prince2-and-scrumagile/

http://www.webgale.com/difference-between-pmp-prince2-and-scrumagile/

http://www.mountaingoatsoftware.com/agile/scrum

http://www.mountaingoatsoftware.com/agile/scrum

http://en.wikipedia.org/wiki/Project_charter

http://en.wikipedia.org/wiki/Project_charter

http://pmstudycircle.com/2012/08/type-of-organization-structure/

Tempus

Thank you for your attention.

Date post:	17-Jan-2016
Category:	Documents
Upload:	jodie-spencer
View:	220 times
Download:	0 times