PROJECT MANAGEMENT

1. PROJECT MANAGEMENT Lecture Notes

2. PROJECT MANAGEMENT • Software Project Managements is an umbrella activity within Software Engineering • Project Management involves the Planning, Monitoring and Control of People, Process and Events that occur as Software evolves from preliminary concept to an operational implementation. • Project Management begins before any technical activity and continues throughout the Definition, Development and Support of Computer Software.

3. PROJECT MANAGEMENT • WHO DOES IT ?Project Managers .Project Managers Plan, Monitor and Control the work of Team of Software Engineers. • WHY IS IT IMPORTANT ? Building a Computer Software is a complex undertaking, particularly if it involves many people working over a relatively long time. That’s why Software Projects need to be Managed. • WHAT IS THE WORK PRODUCT ? ‘’A PROJECT PLAN’’ Project Plan defines the Process and Tasks to be conducted, the People who will do the work and the mechanism to assessing Risks, Controlling Change and Evaluating Quality. Project Plan is produced as Management activities commences

4. THE MANAGEMENT SPECTRUM Effective Project Management focuses on 4 P’s People, Product , Process, Project • A Manager who forgets that Software Engineering is an intensely Human endeavour will never have success in Project Management. Manager who fails to encourage comprehensive Stakeholders communication early in the evolution of a Project Risk building an elegant solution for the wrong problem • The Manager who pays little attention to the Process runs the risk of inserting competent technical Methods and Tools into a vacuum. • The Manager who embarks without a solid Project Plan jeopardize the success of the Product.

5. THE 4’Ps OF PROJECT MANAGEMENT 1. THE PEOPLE • The People Factor is so important that Software Engineering institution has developed a People Management Capability Maturity Model. (PM-CMM). • PM-CMM Defines the following key practice areas for Software People:- - Recruiting - Selection - Performance Management - Training - Compensation - career Development - Organization and work Design - Team Culture Development • Organizations that achieve high level of Maturity in People Management area have a higher likelihood of implementing effective Software Engineering Practices.

6. THE 4’Ps OF PROJECT MANAGEMENT THE PRODUCT (Software Application ) • Before a Product can be Planned:- - Product Objectives and Scope should be Planned - Alternative solutions should be considered - Technical and Management Constraints should be identified. • Without the PRODUCT Plan it is not possible to define:- a) Reasonable and accurate Estimates of Cost and Effective Risk Management b) Realistic breakdown of Project tasks (WBS) c) Project Schedule that provides a meaningful indication of progress.

7. THE 4’Ps OF PROJECT MANAGEMENT THE PROCESS • Software Process provides the Framework from which a comprehensive Plan for Software Development can be established. • A small number of Framework activities are applicable to all Software Projects regardless of Project size or complexity. • A number of Different Task set however, such as :- - Tasks - Milestones - Work Product (Deliverables) - Quality Assurance points enables the Framework activities to be adapted to the characteristics of the Software Project and the requirements of the Project team.

8. THE 4’Ps OF PROJECT MANAGEMENT THE PROJECT • Software Project Development is conducted in a Planned and Controlled way since it is only known way to manage complexity. And yet we still struggle. • In 1998 industry data indicated that 26% of Project failed outright and 46% experienced Cost and Schedule overruns. Although Project success rate for Projects has improved, yet Project failure rate remains higher than it should be! WHY PROJECTS FAIL- An unrealistic Deadlines is established - Changing Customer Requirements - An honest underestimate of effort - Predictable and/ or unpredictable risks - Miscommunication among project staff - Failure in Project Management practice

9. THE 4’Ps OF PROJECT MANAGEMENT THE PROJECT • AVOIDING PROJECT FAILURE - Project Managers and Software Engineers must:- - Heed a set of common warning signs - Understand the Critical Success Factor (CFS) that lead to good Project Management - Develop a common sense approach for Planning, Monitoring and controlling a Project.

10. THE 4’Ps OF PROJECT MANAGEMENT THE PEOPLE AS PROJECT PLAYERS (STAKEHOLDERS) • The Software Process is populated by People as Players or otherwise called as Stakeholders. Who can be categories into one of the Five constituencies:- - Senior Mangers - Project Managers - Software Engineers (Practitioners) - Customers or Clients - End-users • Since the Software Process is populated by People. The Project Teem must be organized in a way to maximize each person’s skills and ability. The Organization of the Project Team is the Job of Project Team Leader may be called Project Manager. • Companies that organizes and Manages their people wisely . Prosper in the long run!!!

11. THE 4’Ps OF PROJECT MANAGEMENT TEAM LEADERS • Project Management is a people-intensive activity, and for this reason, competent Software Practitioners often make poor Team Leaders since they do not have the right mix of people skills • Many Practitioners unfortunately just fall into a Project Manager role and become accidentally Project Mangers.

12. TEAM LEADERSHIP TECHNICAL LEADERSHIP • Jerry Weinberg suggests a Technical Leadership Model (MOI). Based on Motivation, Organization and Ideas (Innovation) • Weinberg also suggests that successful Project Leader applies a Problem Solving Management Style. PROBLEM SOLVING MANAGEMENT STYLE • Concentrate on understanding the Problem to be solved; • Managing the flow of ideas and at the same time letting everyone on the Project team (by word or action) that quality counts and that it will not be compromised.

13. TEAM LEADERSHIP CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANAGER • PROBLEM SOLVING • MANAGERIAL IDENTITY • ACHIEVEMENT • INFLUENCE AND TEAM BUILDING PROBLEM SOLVING • An effective Project Manager can diagnosis Technical and organizational issues that are most relevant; • Systemically structure a solution or properly motivate other Software Practitioners to develop the solution; • Apply lessons learned from past Projects to new solutions and remain flexible enough to change directions if initial attempt s are fruitless.

14. TEAM LEADERSHIP CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER MANAGERIAL IDENTITY • A good Project Manager take full charge of the Project; • Have the Confidence to assume Project Control (when necessary); • Gives assurance to allow good Technical people to follow their instincts. ACHIEVEMENTS • To optimize Productivity of a Project Team:- - Manager must Reward initiative and accomplishments; - Demonstrate through his/her own actions that ‘’Controlled Risk taking’’ will not be punished

15. TEAM LEADERSHIP CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER INFLUENCE AND TEAM BUILDING • An effective Project Manager must be able to ’‘Read People’’, be able to understand verbal and non-verbal symbols and react to the needs of the people sending these signals • Must remain in control in high stress situation. .

16. THE SOFTWARE TEAM The Best Project Team Structure depends on: • The Management style of the organization; • The number of people, who will populate the team, and their skill levels • The overall problem difficulties. MANTEI describes Seven Project Factors that should be considered when Planning the structure of Software Engineering Teams. • The difficulty of the ‘Problem” to be solved • The ‘’Size’’ of the resultant programs in terms of Line Code (LOC) or Function Points (FP) • The “Time” that the Team will stay together (Team Lifetime) • The degree to which the problem can be modularised. • The required Quality and Reliability of the System to be built • The rigidity of the Delivery Date • The degree of Sociability (Communication) required for the Project.

17. THE SOFTWARE PROJECT TEAM TYPES The word “Team” is fairly loosely used in Business world , calling any group of people assigned to work together. But many of these groups just do not seem like Teams. They do not have a common definition of success or ant identifiable “Team Spirit”. What is missing is the phenomenon that is called “Jell” HIGH PERFORMANCE TEAM To achieve a high performance Project Team:- • Team members must have trust in one another; • The distribution of skills must be appropriate to the problem; • Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. JELLED TEAM • A Jelled Team is a group of people so strongly knit together that the whole is greater than the sum of the parts… • Once a team begins to jell, the probability of success goes way up. The team can become unstoppable. A juggernaut for success… Team members do not need to be managed in traditional way, and do not need to be motivated. They have got momentum. • Jelled Teams are significantly more productive and more motivated than average. They share a common Goals, a common Culture, and in many cases a ‘’Sense of eliteness’’ that make them unique.

18. THE SOFTWARE PROJECT TEAM For one reason or another not all Project Teams Jell. Many teams suffer from what is called “Team Toxicity”. FIVE FACTORS THAT FOSTERS A POTENTIALLY TOXIC TEAM ENVIRONMENT • A Frenzied work atmosphere • High frustration that causes friction among team members • A ‘’fragmented or poorly coordinated’’ Software Process • An unclear definition of roles on the Software team • Continuous and repeated exposure to failure.

19. THE SOFTWARE TEAM TEAM ANTITOXINS • To avoid A Frenzied work environment, the Project Manager should be certain that the Team has access to all Information required to do the job: - The major Goals and objectives once defined should not be changed unless absolutely necessary. - Bad news should not be kept secret but rather delivered to the team as early as possible. • Software People often feel Frustration when there is a lack of Authority to control their situation. • Frustration (and Stress) can be avoided if Software team is given as much Responsibilities for Decision Making as possible. • An inappropriately chosen Process (e.g. unnecessary or burden some work task or poorly chosen Work Product) can be avoided in two ways: a) By understanding the Product to be built and the People doing the work. b) By allowing the Project Team to select the Process Model

20. THE SOFTWARE TEAM TEAM ANTITOXINS (continued) • Software Project Manager should clearly refine Roles and Responsibilities of Team members before the Project begins. - The Team itself should establish its own accountability and define a series of corrective approaches when a member of the team fails to perform. • Every Software team experiences small failure. The key to avoid an atmosphere of failure is to establish team-based techniques for Feedback and Problem solving Failure of a team must be viewed as a failure by the Team itself. This leads to a Team-oriented approach to corrective action rather than the finger pointing and mistrust that grows on Toxic Team.

21. THE SOFTWARE TEAM AGILE TEAMSAgile Software Engineering combines a philosophy and a set of Development Guidelines. • The Philosophy encourages customer satisfaction with and early Incremental delivery of Software by Small and highly motivated Project Teams. • The Small, highly motivated Project team also called Agile Team , adopts many characteristics of successful Project Teams and avoids many of the toxins that create problems. • Agile Team are Self-organized. A Self- Organizing team does not necessarily maintain a single team structure but instead uses elements of random, open and synchronous paradigms. • Agile Team members competency coupled with Group Collaboration are considered to be the Critical Success Factor for the team

22. THE SOFTWARE TEAM AGILE TEAMS (Continued) Agile Process models give the Agile Teams autonomy to make Project Management and Technical decisions required to get the job done. • Planning is kept to a minimum • Team is allowed to select its own approach (within the constraints of business requirements and the organizational standards) • As the Project proceeds, the Agile Team self organizes to focus individual competency in a way that is most beneficial to the project at a given point in time. • To accomplish this: • An Agile Team might conduct brief Daily Team meetings to coordinate and synchronize the work that must be accomplished for the day. • Based on information obtained from the daily meetings, the team adapts its approach in a way that accomplishes an incremental of work. • As each day passes, Continual Self-organizing and collaboration move the team towards a completed Software Increment.

23. HUMAN TRAITS OF SOFTWARE TEAM ASoftware Team often struggles with the differing ‘’HUMAN TRAITS’’ of its Team members :- • Some Team members are extroverts; others are introverted • Some people gather information intuitively, distilling broad concepts from disparate facts. Others process information linearly, collecting and organizing minute details from the data provided. • Some members are comfortable making decisions only when a logical, orderly argument is presented. Others are intuitive, willing to make a decision based on ‘’Feel’’. • Some want a detailed Project Schedule populated by organized tasks that enable them to achieve closure for some elements of a Project. Others prefer a more spontaneous environment in which open issues are okay. • Some work hard to get things done well before the milestone date, thereby avoiding stress as data approaches, while others are energized by the rush to meet a last minute deadline. It is important t o note that recognizing Human Traits is the first step towards a building a creative Project Teams that Jell.

24. SOFTWARE PRODUCT A Software Project Manager is confronted with a dilemma at the very beginning of aSoftware Engineering Project for the following reasons: • Quantitaitive Project Estimates and an Organized Plan are required but the Information (solid information) is not available as yet. • Project Requirements may be fluid, changing regularly as the project proceeds. Yet a plan is needed “immediately”. ! A detailed analysis will provide all the solid information for Quantitaitive Estimates and Project Plan . But Analysis often takes weeks or months to complete The ‘’Scope’’ of the Product must be established and bounded at the very beginning of the Project.

25. SOFTWARE SCOPE The first activity of Software Manager is to determine the Scope of Software. Software Scopeis defined in collaboration with the User Management by asking the following Questions onthe following areas:- - Software Context, - Information Objectives - Function and Performance of Software • Software Context – How does the Software to be built fit into a larger System, Products or Business Context, and what Constraints are imposed as a result of the Context? • Information Objectives – What Customer – visible Data Objectives are produced as Output from the Software? What data objectives are required for Input? • Function and Performance – What Functions does the Software Perform to transform Characteristics to be addressed? Software Poject Scope must be Unambigious and understandable at the Management and Technical level’’. A Statement of Software Scope must be bounded. (i.e.Quantitative data must be stated explicitly) Constraint and / or Limitations are noted and mitigating factors (e.g. desired algorithms are well understood and available in C++) are described .

26. SOFTWARE SCOPE PROBLEM DECOMPOSITION During the Project Scoping no attempt is made to Decompose the Problem. Rather decomposition is applied in two major areas :- • The Functionality that must be delivered • The Process that will be used to deliver it Human beings tend to apply a Divide –and- conquer strategy when they are confronted with a complex problem. A Complex Problem is partitioned into smaller problems that are more manageable. We apply the ‘’Divide andConquer strategy’’ to partition a Product into Smallerpieces so that can be managed better, as Project Planning begins. Software Functions described in the Scope, are evaluated and refined to provide more detail prior to the beginning of Estimation. Since both Cost and Schedules are Functionally oriented, some degree of Decomposition is often useful. As the Statements of Scope evolves, a first level of Partitioning naturally occurs.

27. SELECTING PROCESS MODEL The Project Manager must decide which Process Model is most appropriate for : • The Characteristics of Product itself • The Customers and thePpeople who will do the work (users) • The Project Environment in which the Software works • After Selection of a Process Model , the Software Team then defines a Preliminary Project Plan based on the set of ‘’Common Process Framework’’ (CPF) Activities. • Once the Preliminary Project Plan is established, Process Decomposition begins. A Complete Project Plan, reflecting the Work Tasks required topopulate the Framework Activities can be created .

28. MELDING THE PRODUCT AND PROCESS • Project Planning begins with the melding of Product and the Process. • Each Product Function to be engineered by the Software Team must pass through the ‘’Set of Framework Activities’’ that has been defined for a Software organization. Assuming thatan Organization has adapted the following ‘’Set of Common Process Framework Activities’’. • Communication • Planning • Modeling • Construction • Deployment • Set of the Common Process Framework Activates are listed in the top row of a matrix and the Software Engineering Work Tasks entered in the following rows. • The team members who work on the Product Function will apply each of the Framework activities to it.

29. MELDING THE PRODUCT AND PROCESS • The job of the Project Manager is to Estimate Resource requirements Start Dates and End Dates for the tasks associated with each cell, and work Products to be produced as a consequence of each task.

30. MELDING THE PRODUCT AND PROCESS • The Process Framework is invariant and serves as the basis for all Software work performed by Software organization. • The Actual Software Engineering Tasks (i.e. Work Task) do actually vary. • Work Tasks must be adapted to the specific needs of the Project. • Process decomposition commences when the project manager asks, ’’How do we accomplish this Framework Activity’’? For example: A small relatively simple Project might require the following ‘’Work Tasks’’ for the ‘’Communication Activity’’: 1. Develop list of clarification issues 2. Meet with Customer to address clarification issues 3. Jointly develop a statement of Scope 4. Review the Scope with all concerned 5. Modify the Statement of Scope as required

31. THE PROJECT (The 4 P’s of Software Mangement)THE PROJECT In order to manage a Successful Software Project, we must understand What can go wrong so that the problem canbeavoided, John Reel defines 10 Signs that indicate an Information Systems Project is in Jeopardy:- • Software People don’t understand their Customers’ needs • The Product Scope is poorly defined • Changes are managed poorly • The chosen Technology changed • Business needs change or ill defined • Project Deadlines are unrealistic • Users are resistant • Sponsorship is lost (or never obtained) • The Project Team lacks People with appropriate skills • Managers / Practitioners avoid best practice and Lessons learned.

32. AVOIDING PROBLEMS SIGNED BY JEOPARDY Jaded Industrial Professionals often refer (half facetiously) to the 90 – 90Rule when discussingparticularly difficult Software Projects. The seeds that lead to the 90 – 90 rule are contained in the 10 Project Jeopardy Signs. 90 – 90 RULE • The first 90 % of a System absorbs 90 % of the Allocated Effort and Time. • The last10 % takes the other 90 % of the Allocared Effort and Time. John Reel Suggests a Five-part Common-sense approach to avoid Project Problems:- • Start with right foot • Maintain Momentum • Track Progress • Make Smart Decision • Conduct a Post-mortems Analysis

33. AVOIDING PROBLEMS SIGNED BY JEOPARDY 1. START WITH RIGHT FOOT • This is accomplished by working hard to understand the problem that is to be solved and then setting realistic objectives and expectations for everyone who will be invloved in the Project. • This is achieved by building the ‘’Right Team’’ and giving the Team the autonomy, authority and technology needed for job 2.MAINTAIN MOMENTUM : Many Project get off a good start and then slowly disintegrate. To maintain momentum:- • The Project Team should emphasize quality in every task it performs. • The Project Manager must provide initiatives to keep ‘’Staff turnover’’ to an absolute minimum. • Senior Management should do everything posssible to ‘’Stay out of the Project Team’s way’’. • (Management should reduce bureaucracy to a minimum, Eleminate exraneaos meetings and eliminate dogmatic adherence to Project rules. The Project team should be self-organizing and autonomous.

34. AVOIDING PROBLEMS SIGNED BY JEOPARDY 3.TRACK PROGRESS • Progress is tracked as Work products (i.e Specification, Source code, Test results etc) are produced and approved (using Formal technical reviews), as part of a Quality Assurance activity. • Additionally, Software Process and Project Measures can be collected and used to ‘’Assess Progress Against Averages’’ developed for the Software Development Organizations. 4.MAKE SMART DECISION In essence, the decisions of Project Manager and the Software Team should be ‘’keep ıt sımple”. Whenever possible decide to:- • Use , commercial ‘Off- the -shelf Software’’ or Existing Software components. • Avoid Custom Interface when standard approaches are available. • Identify and then avoid obvious risks, • Allocate more time than you think is needed to complex or risky tasks.

35. AVOIDING PROBLEMS SIGNED BY JEOPARDY 5.CONDUCT A POSTMORTEN ANALYSIS • Establish a Consistent mechanism for extracting lessons learned for each Project. • Evaluate Planned and Actual Schedules • Collect and Analyze Software Project Metrics • Record findings in written form

36. THE W5HH PRINCIPLE BOEHM suggest an organizing Principle that scale down to provide simple Project Plans for simple Projects. Boehm suggests an Approach that addresses the following areas: • Project Objectives • Milestones and Schedules • Responsibilities • Management and Technical approaches • Required Resources

37. THE W5HH PRINCIPLE W5HH (WWWWWHH) Principle is based on a series of questions that leads to a definition of key Project Characteristics and the resulting Project Plan. • Why is the System being Developed? • What will be done? • When will it be done? • Who is responsible for a function? • Where are they organizationally located? • How will the job be done technically and Managerially? • How much of each resource is needed?

38. THE W5HH PRINCIPLE Why is the System being Developed? The answer to this question enables all parties to asses the validity of business reasons for the Software work. (To justify the expenditure of People, Time, and Money for the Business purpose) What will be done? The answer establishes the task set that will be required for the project When will it be done? The answer helps the Project Team to establish a Project Schedule by identifying when Project Tasks are to be conducted and when Milestones are to be reached. Who is responsible for a function? The answer helps to define the roles and responsibilities of each member within the Project team. Where are they organizationally located? Not all roles and responsibilities reside within the Project team itself. Users, Customers and other stakeholders may have responsibilities as well. How will the job be done technically and Managerially? Once Product Scope is established a Management and Technical strategy for Project must be defined. How much of each resource is needed? The answer is derived by developing estimates based on answers of the above questions

39. CRITICAL PRACTICES A team of Software Engineering experts has developed a list of ‘’Critical Software Practices for Performance-based Management; These practices are consistently used by , and considered critical by , highly successful Software Projects and Organizations whose ‘bottom line’ performance is consistently much better than industry averages. Critical Practices include the followings • Metric-based Project Management • Empirical Costs and Schedule Estimation • Earned Value Tracking • Formal Risk Management • Defect Tracking Against Quality Targets • People Aware Management The Critical Practices is also known as QUICK LOOK QUESTIONS.

40. SUMMARY • The Project Management activity encompasses Measurements and Metrics, Estimation and Scheduling, Risk Analysis, Tracking, and Project Control . • The pivot element in all Software Projects is ‘’PEOPLE’’. • Software Engineers can be organized in a number of different Team structures that ranges from Traditional control hierarchies to ‘’Open Paradigm’’ Project Teams. • A variety of coordination and communication techniques can be applied to support the work of the Project Team. In general, Formal reviews and Informal person-to-person communication have the most value for Software Practitioners. • Each of the Project Management Activity is considered in the chapters that follow.