CSE403 Software Engineering Autumn 2001 Project Management Gary Kimura and Will Portnoy Lecture #10 October 18, 2000

Today Understand that there are different approaches to project management for software Go over some of those approaches Offer alternative and guidelines for your class project Managing schedules

Project management What percentage of the effort to date has been spent writing code? What percentage has been spend working through requirements and design? What percentage has been spend in meetings? When does the real coding start?

Problems with managing projects include Figuring out and coordinating schedules Handling communication among the team –The figure shows a rough notion of the cost of team communication –The theory is that about 25% of each group's effort is spent in communication, with this cost applying recursively –As Brooks observes, the worst case of this is adding people to a late project, which tends to make it even later Making decisions Recording decisions Managing egos What else?

Team structure Brooks talks about the desire everyone has for a small, sharp team 10 or fewer people All of them brilliant All of them focused on the task at hand But he observes that this is too slow a way to build a really big system And rightly so…

Why? Time Brooks: take a 10 person team composed of people all 7x better than the worst 5x to 25x are within known ranges Assume OS/360 was built by the worst Assume a small team has a 7x communication benefit Assume no turnover of the team Assume 5000 person-years for OS/360  10 actual years for the task Now, do the same estimates for NT 5.0 with 60,000,000 lines of code!

Chief Programmer Team An alternative idea is to restructure a classic big team to get the benefits of the small, sharp team (ability and focus) with the benefits of a bigger team (overall speed) The key is to design the positions on the team very carefully

Y2K Most of these specific (lower-level) job descriptions are clearly out of date “…a team will rarely need its own machine and operating system crew” “All computer input goes to the clerk, who logs and keys it” But the idea of focusing on how to break up the team into well-defined jobs is, of course, still extremely pertinent

Chief Programmer Team An underlying theme of this approach is that a smart person understands the domain and defines an appropriate architecture Then the subpieces are spawned off to people who are talented programmers but who have little (or less) knowledge about the project In practice I wonder if this works very well at all –Need commitment and buy-in from all parties –Need to build team synergy

Aside: outsourcing Over the past years, there has been an increased interested in outsourcing significant pieces of software projects In particular, the interest has been to use cheaper labor in places like India, China, Ireland, etc. –There is a big political issue related to this, which is the question of granting H1-B visas to people from other countries to work in high-tech in the U.S. This in many ways resembles aspects of the chief programmer team — “Give them the spec and let them code!”

More on outsourcing A serious problem with the outsourcing version of coding is the increased distance between the programmers and the people who own the requirements Communication is almost entirely by , travel is costly and time consuming, etc. I believe this leads to less effective communication, significantly increasing risks

Some Microsoft job titles Program Manager –Maintaining the big picture. Weighing risks against costs. Understanding many disciplines. Keeping a variety of specialists on the same page. Sewing all the components of a project together to make world-class software projects happen on time, on budget. Software Design Engineer –Working with other product team members from the beginning of the product cycle through release, our SDEs design and implement sophisticated products... SDE in Test –Deeply involved in every phase of the product cycle, our SDEs in Test devise and implement test plans and strategies. … It's a specialized skill that requires the ability to effectively second- guess our other developers. Software Test Engineer –As the strongest advocate our end-users have, Microsoft Test Engineers develop and execute test plans and scripts designed to detect problems and ensure the quality...

Last years team structure Well-defined team structure (dev, test, performance) Medium-sized teams (10 students) One coordinator Impossible to schedule meetings

This years team structure Hierarchical divided up into specific areas One assigned coordinator for the whole team Each sub-team works “quasi” independently of the other teams But communication and buy-in by everyone is still a must A way to make decisions needs to be agreed upon A very common problem is to fight for a long time over decisions for which either alternative is adequate; often, making a decision is more important than which decision is chosen. Most often a good manager is the decision maker if consensus cannot be reached in sufficient time

Decision making Making decisions is something we do all the time in a project The biggest risk, in general, is not that we make a bad decision It is that we delay making any decision past a point of no return You should probably spend relatively little time deciding between two pretty strong alternatives This is perhaps especially true in your project, given the incredibly compressed schedule

Recording decisions In your meetings you will be making a lot of decisions Some of you’ve probably already made are who will do what, what will the requirements be, who will write up what, what coding standards (if any) will we use, how will we name our variables, etc. You might even still have some major design decisions to work through. You cannot record all your decisions in writing…but you’d better record the key ones! Decide where these are recorded and how. How have you been recording and keeping records?

Running meetings You’ve already had a few meeting. Here are some tips: Have an agenda Have a person responsible for keeping the meeting on the agenda Have a person record key decisions This person can rotate or can be assigned to someone who is good at this by nature Show up to the meetings Start them and end them on time It may be that your team’s ability to succeed is driven as much by things like how your meetings run as by how well you cut code

Artifacts The following are two documented/analyzed ways to aid in managing projects You may find these artifacts helpful for your project management task Some, of course, may appear in your actual project, as well As always, (a) use what you want and (b) don't over do anything!

The primary example is a Gantt chart to show the link between tasks and time A Gantt Chart maps tasks to dates There is a row for each task; the columns represent dates This makes it easy to see the schedule So it’s often a good way to build an initial plan, to view the schedule, and to make adjustments Task linking is a constraint that says, “Task x cannot start until Task y completes”

PERT charts Displays tasks and task dependencies as a network diagram or flowchart A node represents each task and a line connecting two boxes represents the dependency There are some nice software packages that help with these charts.