CSE 516 Introduction to Software Engineering. Lecture 4: Project Management

1. CSE 516 Introduction to Software Engineering.Lecture 4: Project Management Sanjeev Qazi sqazi@cse.ogi.edu

2. Project Management • What? • Project Management has to do with effective utilization of resources available to a project with the end goal of making the project a success. • It is the techniques and concepts used to effectively (hopefully:=) manage a project and lead it to success.

3. Project Management • Why? • To achieve the intended goal (typically a product or service) within the business and technical constraints, i.e., to achieve the goals within the targeted cost and on schedule. • Business goals can be: • Market window • Competitive features • Cost, etc. • Technical constraints can be: • Limited technical resources( human and/or infrastructure ). • Immature technology ( language, debug environment, 3rd party libraries, etc. ) • …

4. Various roles • The Project Manager (PM) • S/W Architect (SWA) • Lead Developer(s) • Developers

5. Project Manager Role • Project Manager (PM): • PM is the person with the overall responsibility of the project. • Other people in the project report to the PM (directly or indirectly). • PM role is primarily managerial, but may involve technical aspects also. Usually technical knowledge goes a long way in helping to do an effective job. • This is where the “buck” stops.

6. Software Architect • S/W Architect (SWA) • SWA is the person responsible for the overall architecture of the software. • For a large software project, there may be more than one SWA. • SWA will typically have a lot of interaction with Lead Developers. • SWA role is primarily technical, but can have some managerial aspects also (typically not much).

7. Software Architect • What do we mean by overall architecture? • High level components in the software system. • How they interact. • Technologies used (COM, XML, etc.) • Languages used ( C++, Java, Asp, Java Script, VB script, … ) • Protocols used (communication, security, etc.) • Can also have like a Security Architect who primarily deals with security protocols, threat assement, vulnerability assesment, etc.

8. Lead developer • A project may have one or more lead developers (LD). • LDs have developers reporting to them, although not necessarily in managerial aspect but more from a technical point of view. • LDs are responsible for resolving technical issues and providing guidance when needed. • LDs will typically have a lot of communication with SWAs. • In some projects, LD and SWA role could be played by the same person.

9. Developers • Developers are typically the people who are responsible for design, implementation and unit testing of their “pieces” ( modules or classes or …) • Code from all developers is eventually put together and forms the product.

10. Roles • PM and SWA play a very critical role in a project, since they are responsible for defining the managerial and technical strategy for the whole team. • A team can have great LDs and Ds, but if the PM is not doing a good job of managing the team, the project wont be a success. • On the other hand, a great job by the PM does not guarantee project success. It is, after all, a team effort, so all players need to play well.

11. Roles • If a developer delivers low quality code, or is not pulling his/her weight, then it is relatively easy to rework the piece he has done, or maybe replace him. • However, if the SWA or the PM does not measure up to the mark, it has a much more detrimental effect on the project. • So, a developer messing up will cause a hit to schedule, but on a smaller scale compared to PM or SWA messing up their jobs.

12. Things that can go wrong • If a team is not being managed well, some of the problems that can happen are: • Regularly missed milestones or • Low quality or • Lack of accountability or • Improper distribution of tasks or • Improper communication either among the team members or between management and the team. • All of these eventually lead to team demoralization where even the most productive team members will not be productive anymore…

13. Why is software project management hard? • "Malleability" of software is its strength as well as its weakness. • You don’t see anything physically being developed, so it is not easy to tell accurately what is done, what is missing, and the quality of the work. • Since you don’t really "see" the product (you just use it), there is lesser incentive for the developer to design and build it well ( the internals). • In the case of building a skyscraper, the whole product is visible, its stress tested from the day its open to public, there are no beta test phases or rebuilding the skyscraper. Architecture and development has to be solid by the time its claimed to be "done".

14. Why is software project management hard? • Software projects often fall into the pressure of just making it work. And then someone pays for it later. • You have to rely to a great extent on the developers' word/judgement. • Software processes are not well understood in the software engineering community. • Because of the nature of software, its not just software engineers that develop sofware, folks from other disciplines do it too. • Example: Electrical engineers writing software for CAD type tools… no offense to anyone :=)

15. PM responsibilities • A PM has a variety of responsibilities: • Determine if team members are overloaded (or underloaded), if they are overcommiting (undercommiting). • Ensure proper and open communication. • Accountability • Schedule • Quality • Features

16. PM responsibilities • Building the schedule and milestones and tracking them… Microsoft Project or similar tools. • Project planning and goal setting. • Growth and development of team members. • Team building skills. • Keep an eye on any personal issues. • Be persuasive, influence the team with proper knowledge / reasoning rather than using his/her position. Its not the army…

17. PM responsibilities • Communication • To the team (passdowns): • Communicate high level goals and any subsequent changes to the team. • To upper management: • Communicate project status. • Raise issues that may require upper management intervention or may need to keep them “in the know”, unless the issue can be "locally" resolved without affecting any milestones visible to the upper management. • Be a good listener • Be good about following up.

18. PM responsibilities • In many ways, the reward of a PM is to see the project thru without any major issues. • PM needs to look at it as his/her project, ie, assume ownership of all issues. • This does not mean the PM has to solve all the problems. Issues may be assigned to others for resolution, but PM drives it and is responsible for it. • A PM should be aware of issues before they become problems. • Should be good at handling stress… the last thing you want is a PM who is stressed and shows it, as that will quickly spread to the team.

19. Project team organization • A project can be organized in one of the following ways (not exhaustive): • Functional • Project oriented • Matrix • Horizontal and/or vertical • Geographic considerations.

20. Functional organization • Here, a group has all the people related to that field, and these people work on various projects across the company. • This group is the technical base (in that field) and loans technical consultants to other groups or projects in the company. • So, a person may be working full time on some projectA, or half time on projectA and projectB.

21. Functional organization • Advantages: • The technical knowhow is available in one place ( i.e., in this group). • Technical discussions/brainstorming can happen among the group members, which usually leads to good information/decisions. • When a projectA gets over, folks can start working on another project (or may already be working part time on another project). • Good for technical continuity in case some people leave.

22. Functional organization • Disadvantages: • Folks may not feel that they "own" a piece of the project they are working on. • As a result, the responsibility or drive to make the project successful may not be there. • Folks working part time on more than one project may get into conflicting priorities situation with respect to their time / deadlines. Multiple bosses situation.

23. Project Organization • In this type of organization, the resources are divided according to the project they are working on. • The group is a stand alone group “in a sense”. • This is more vertical type than the functional organization, which can be thought of as more of a horizontal type organization.

24. Project Organization • Advantages: • People identify with the project, and are responsible for its success or failure. • No conflicting priorities ( at least not across multiple projects ). • Single boss to please :=) • Functional structure is bypassed, so communication and decision making is quicker. • Project organization is simpler.

25. Project Organization • Disadvantages: • Can lead to duplication of resources across the company because every project needs resources for itself. So they are staffed up, and when a project ends, these resources need to find a new home. • Can become expensive due to above disadvantage (in terms of salary overheads).

26. Matrix Organization • A combination of the Functional and Project oriented organization. • It tries to draw upon the advantages of the two. • Advantages: • Emphasis is on the project. • Prevents duplication of resources. • Better utilization and balance of resources across the company. • Once a project is over, the members go back to their functional “area” and get reassigned to another project. • Disadvantages: • Multiple bosses situation.

27. Software Risk Management (SRM) • SRM is very important for a software organization. • It outlines the process (without making it specific to an organization) that can be implemented and followed to successfully manage software risk. • Not limited to just software development, but extends to acquisition, supply (as in software supplied by external agency/contractors), operations and maintenance of software. • It applies to both technical as well as managerial work activities.

28. SRM – Technical risks • Technical risks are associated with performance of the software product, which can be any of the following: • Functionality: Performance to requirements agreed upon. • Quality: Meet customer expectations. • Reliability: Work for an extended period of time, without requiring restarts. • Usability: Eases of use by the customer. • Maintainability: Software should be maintainable (bug fixing). • Extensible: Since customer requirements keep on growing, the software features need to grow too.

29. SRM – Cost risks • Cost risks associated with the cost of software development. This includes: • Budget: Keeping the costs within the approved budget for the project. • Variable costs: Identifying and managing costs varying with the amount of activity, like software licenses. • Profit/Loss Margin: Prediction and control of the expected profit margin.

30. SRM – schedule risks • Schedule risks involve: • Flexibility: Ability to extend or compress the schedule and with the expectation of completing the tasks. • Meeting milestones: Ability of the team to meet the agreed upon milestones.

31. Risk Management • Risk Management involves: • Risk Identification • Any new or improved technologies to be used? • Document all assumptions ( technical, usage, environment/platform, etc.) • Risk Analysis • How probable? • Consequences? • Risk Planning • Accept, avoid, mitigate, ignore • Risk monitoring

32. Risk Management • Types of risks: • Technology / language: • may decide not to move to the latest version of some software or platform and stay with something that has been tested and used for a while. • People • Should try to avoid developing islands of knowledge, so that knowledge is spread in the team. • Tools • Use latest tools, or stay with older ones. • Look at tool training issues, availability of support in case of bugs. • Requirements • Ambiguous or incomplete requirements. Face to face meetings with customers to mitigate this problem. • Estimation • Optimistic estimates. Unforeseen issues can come up.

33. S/W estimation techniques • Analogy • Rule of Thumb • Expert Judgment • Designing to Cost and Schedule • no historical data, so prioritize requirements, develop in an iterative manner until the delivery date. • LOC is not really a good measure of software size or complexity. • LOC depends a lot on coding styles, and has pretty much no bearing on how much time it takes to write it. • 1000 lines of some complex algorithmic code could be much more effort than 10000 lines of code that is relatively straight forward.