• Project Planning and Management
• : Online Reading
• : Introduction -- Planning is everything but the plan is nothing.
• : Masterly management of the unexpected
• : Brookes's Law: Adding staff to a late software project makes it later.
• : Levels of planning
• : Personal Planning
• : Estimating and Planning
• : Practice -- Use UML Activity Diagrams for planning
• : Hints with planning diagrams
• : Can we face a critical path at the start of a project
• : Which do I prefer: Visio or Dia
• : What is the purpose of the critical path method
• : Explain CPM
• : How do you decide if an activity is critical
• : If one activity helps another but it not necessary -- is it a predecessor
• : Planning Smell -- Indecisiveness
• Story -- My Final Year Project
• Management
• : Complexity
• : Meetings
• : Success or Failure
• : Control
• : Controling access to Artifacts
• : Version Control and Software Configuration Management
• : Useful Lists for Managers
• : Readings on Management
• Questions
• : Is there a point where the accumulation of new requirements add up to a new project
• : What is a Change Control Board for
• : What is the most common reason for project failure.
• : Does removing people from a project speed up its development
• Discussion topics
• Exercises on Critical Path Methods
• Online Resources
• : Story -- How Fast can you build a house?
• : Joke
• : Coding Horror -- Big Projects are different
• : Example Diagrams online
• : Critical Path Method Online
• : Another Example
• : Tools for project management
• : Scrum Meetings on Wikipedia
• : Software Configuration Management on Wikipedia
• : What is the best way to estimate the time to develop software
• Further Reading on Management
• : Fred Brookes -- the Mythical Man Month
• : Joel Henry
• : George Stepanek
• : Craig Larman
• : Frank P Ginac
• : Susan Snedecar
• : Managing Projects with GNU make, 3rd Edition by Robert Mecklenburg
• : Do the Readings on Management make me an OK manager
• Review Questions
• : Simple Example
• : A JAD Meeting
• : My First PHP Page
• : Setting up a Seminar
• : Review Management
• Typical Quiz on Critical Path Methods
• Abbreviations

Project Planning and Management

Online Reading

Part of the reading on this topic is on the Wikipedia. Please study this [ PERT ] before studying the reading below.

Introduction -- Planning is everything but the plan is nothing.

The quote is from a successful general in the 2nd world war: Eisenhower.

From planning how you get to work on time, to planning the next step in your team project, thru to sorting out a plan for a big project.... the same technique can be used. You can handle routine daily planning and small projects using pencil and paper. Large projects need a computerized tool. But the same ideas and algorithms are used for both small and large projects.

You should already have met scenarios: lists of simple steps that are executed one after another. There is only one path through a scenario. There is only one way of executing it. In a typical planing situation you have a list of steps, but the order is not completely determined. Usually you can save time (and so money) by doing things in the optimal order. The Critical Path Method is a powerful tool for doing this. The critical path is a set of activities that have to be done on time or the whole project will be late. Every plan has one. These are the important activites to watch as the plan evolves.

Masterly management of the unexpected

This page also has notes on management. Managers have to plan things. But they have other things they must do. They must motivate and organize people. They make the tough decisions, set goals for subordinates, provide resources, and .... get out of the way. This set of notes has a some introductory thoughts, some procedures and artifacts needed when managing a development project, and a reading list that may help.

Brookes's Law: Adding staff to a late software project makes it later.

Software development is usually a learning experience. As the project progresses the team learns facts about their environment, their technology, the problem, etc. . More they create new facts: the software architecture, the project coding standards, what each person does, ... Now, if you add new people, the team has to stop developing the software and, instead, teach the new people the above information. This slows down (even stops) development. The project goes further behind schedule, and so more people are added... See MMM (The Mythical Man Month) below.

So..... (1) get enough people first. (2) software development is more like research than manufacturing so some traditional planning techniques tend to make failure more likely. (3) First do things that provide the information to estimate the project -- you need to know if you need more people at the start of the project, not later.

Levels of planning

1. National Plans
2. Enterprise Level Planning
3. Department and Mid-level Planning
4. Team Planning and Organization
5. Individual level: see [ Personal Planning ] below

Personal Planning

Here are some points made in a recent article based on the authors experince. You would be wise to to take note of them.

Rainsberger07

1. J B Rainsberger
2. Personal Planning
3. IEEE Software Magazine V24n1(Jan/Feb 2007)pp16-17
4. =IDEA PLANNING WORK BREAKDOWN CSCI372
5. It pays for a programmer to organize their work day as a series of tasks.
6. Publish the task list and check off items as they are completed.
7. Define tasks in terms of completion -- what conditions determine that the task is complete -- tests, reviews, .....
8. Keep tasks small enough to be done in 90 minutes.
9. Small tasks help spot more things that have to be done.
10. Consequence: less work done but more working software delivered.

Estimating and Planning

1. Time and cost of a project depend critically on the size and scope of the project, the resources you can win for it, the novelty of the project, and any unusual constraints put on the product or the team.
2. Always break down a complex piece of work into simpler steps.
3. Look for steps that are novel -- these are risky and should be done earlier rather than later.
4. Work out what steps must be complete before other steps can start. "predecessors".
5. The result is called a "Work Breakdown Structure" -- -- --(WBS)
   
6. You can show a WBS as activity diagrams or other charts (below). Wise managers do this. I had a 5-year plan for the Computer Science Department on display in the department office when I was founding chair.

   Example -- Implementing my PICT system.

   During my Ph. D. I created a graphic package (PICT) and I worked out how long it would take a team of programmers to port it to a new platform. It had 8 distinct modules and I planned two levels of testing -- the machine code and the high level language code. I figured as a result that 2 programmers could do the work in less than 8 weeks. I could also show that adding a third programmer wouldn't speed up the process.

   Tools: MS Project, Visio, UML, etc.

   You can use pencil and paper, Visio, and Dia. In a group use a board -- it's fun. There are lots of piece of software that can be used -- see the online resources at the end of thie reading.

   Example -- breakfast

   ---

   

   This is an example of a sequence. Note we can't eat a hard boiled egg without first cracking it or boiling it. This defines a single possible scenario. We add up the durations to figure the time to completion. In turn this means that if it takes longer to boil the egg then the whole sequence will either be delayed, or we have to do the later steps faster.

   Software development has lots of sequences: write code before compiling and make it compile before you you test it. Another example: find out the problem, before you start to solve it.

   Here is an example of a parallel structure.

   

   The time to complete is the maximum of the two times. Usually the time for the whole structure depends on just one of the to processes. If that process takes too long then the whole is delayed. And the other process can take a longer time without delaying all. We say the the longer process is ont the critical path and the the shorter process has float or slack.

   In the paralel case we have two or more scenarios depending on which task we start first. There is no predefined sequence. We can choose the sequence. We can even try to multi-task the two parallel processes at the same time.

   In software development this happens when you have several people coding and the work is broken into independent modules. For example: Designing screens and reports. Or preparing user manuals and help screens in parallel with coding and testing. It also happens when there is a single person but machines (the toaster above) can carry out the actions.

   ---

   Example -- eXtreme Programming

7. Here is an example for a one week iteration of eXtreme Programming. This shows a WBS as a table. Note: times (durations) are in hours.
   Table

   #	Task Description	Predecessor	Duration
   1	Get new Requirements	-	2
   2	Negotiate iteration functions	1	4
   3	Programmer writes Unit Tests	2	3
   4	User plan acceptance tests	2	5
   5	Modify code until test all succeed	3	5
   6	Users do Acceptance tests	5,4	2
   -	Done	6	-

   
   (Close Table)
   
8. I've found that tables like this are an easy way to document a WBS but they are error prone and not easy to grasp. Don't trust them until you've drawn a diagram of the same structure. Even then, show them to other people -- and expect more errors to appear.

   

9. All methods use what mathematicians call "directed graphs" -- see Math272.
10. All CPM methods record and display what tasks (= activities) must be done and show, graphically the Predecessor-Successor links. All predecessor tasks must be done before all successor tasks. You get networks of tasks. So some people called this Network Planning. The graph has the name and expected duration of each task put on it. Then you can calculate the earliest time the activities can start and so the shortest time for the project. From, this you can find how late tasks/activities can start with out delaying the project. From this you discover a path through the graph of "Critical" tasks -- the "Critical Path". These tasks must start and finish on time if the project is to finish according to schedule.

    The Critical Path Algorithm

    
    The algorithm assigns four times to each task:
    Table

    Time	Abbreviation	Constraint
    Earliest start	ES	Immediatly after the last predecessor task finishes
    Earliest finish	EF	= ES + duration
    Latest Finish	LF	Immediatly before the first successor task starts
    Latest Start	LS	= LF - duration

    
    (Close Table)
    Algorithm:
    
    1. Initially: Tasks/activities with no predescors start at time zero.
    2. Forward: earliest start is the maximum of predecessor's earliest finishes.
    3. Tasks/activities without successors determine time for the project: the maximum of all the Earliest finishs.
    4. The time for the project is the latest start of all activities that have no successors. This is also called the project lead time.
    5. Backward: latest finish is the minimum of the following latest starts.
    6. When you get to the tasks/activities with no predescessors -- the lastest start should be zero again.
    7. Slack::= earliest - latest.
    8. Note: Float = Slack.
    9. Set something critical is true if and only if it's Slack is 0. This means it can not be held up without effecting the successor activities.
    10. Find the Critical Path -- a sequence of critical (slack=0) activities that starts from the first activity to the last activity. Thus a delay in these activities can delay the whole project.
    
    
11. You can do the calculations on a diagram and record the results in a table. Here are the computed times (no slack yet) for the XP example:
    Table

    #	Task Description	Predecessor	Duration	ES	EF	LF	LS
    1	Get new Requirements	-	2	0	2	2	0
    2	Negotiate iteration functions	1	4	2	6	6	2
    3	Programmer writes Unit Tests	2	3	6	11	9	6
    4	User plan acceptance tests	2	5	6	11	14	11
    5	Modify code until test all succeed	3	5	11	14	14	11
    6	Users do Acceptance tests	5,4	2	14	16	16	14
    -	Done	6	-	16	16	16	16

    
    (Close Table)
    

    Special Notations

    Gantt charts

    There are example in the Wikipedia reading of this notation. Plot time on the x axis and tasks down the y axes. They look good so use as an audio-visual aid in presentations and as a figure in reports. Also good for posters in the project's team room. High light the finished work. I only use these when I can get them drawn for me.

    PERT

    There are example in the Wikipedia reading of this notation. I don't like the PERT notation of arrows for activities and bubbles for events because activities often have many prerequisites etc. You have to add "dummy activities" that take no time to express multiple prerequistes. I was taught this in the 1960's but rapidly moved away from it.

    However PERT has a very useful approximation:

    1. Expected::= (Best+4*Most_Probable+Worst)/6.

       Use this formula to get the expected durations of activities in CPM. It can also be used in any estimating problem where we have best, worst, and most likely values.

       CPM Notation

       There were example in the Wikipedia reading of this notation.

       Each node records the following data representing activities:

       • Task data: id and name, duration, earliest start(ES), earliest finish(EF), latest finish(LF), latest start(LS).
       • Slack and Critical Activities are calculated and added to the boxes.
         Table

         Earliest start	Duration	Earliest finish
         -	Task Name	-
         Latest Start	Slack	Latest Finish

         
         (Close Table)
         

       I have seen several layouts for the parts in an activity for the Critical Path Method. I like the critical path method and have used the common notation until recently. But it forces you to record most start and finish times twice because the Earliest Finish of a task will equal the Earliest Start of the next task.

       UML Activity Diagrams

       These are the best notations I've seen for doing Network Planning.
       • Draw explicit parallel symbols
       • Matching traditional to the unified notation

         

       • Add a unique Start state as predescessors of task/activities that have no predescessors.
       • Add a unique Terminal state as a successor of all taks/activities that have no sucessor.

    . . . . . . . . . ( end of section Notations) <<Contents | End>>

Practice -- Use UML Activity Diagrams for planning

You can do CPM easily in the UML.
• Example
  
  1. Attach a duration to the activities.
  2. Attach earliest times to transitions. Put earliest above/on left of the arrow.
  3. Calculate the latest times and put below/on the right of the arrows.
  4. Highlight the critical activities where latest = earliest + duration.
  
  
• Visual Cheat sheet for doing CPM in the UML

  

Hints with planning diagrams

1. Turn your paper sideways, and set your "Print Setup" to landscape before you start.
2. Every project has a single start point and a single terminator.
3. Watch out for branches that go nowhere.
4. Watch out for events/predecessors that are redundant before you do the CPM.

. . . . . . . . . ( end of section Hints with planning diagrams) <<Contents | End>>

Can we face a critical path at the start of a project

Yes -- the critical path starts with the first step. All WBS have a critical path and it always connects the start to the end of the project. It is a property of WBSs! However only one of the initial activities is usually on the critical path.

Which do I prefer: Visio or Dia

Somehow I like Dia better because it is free and not pretentious. I dislike paying for a program that tries to do so many things that I don't want.

What is the purpose of the critical path method

It tells you much time you will need to complete a project if you do things in the right order. It also tells you what steps/actions/tasks in the project that can be started late with out delaying the whole project. It also calculates for each non-critical task, how much lateness is allowed.

Explain CPM

Hmmmmm --- best thing is to try it. It is a quick and simple calculation that gives you some useful information about your project.

How do you decide if an activity is critical

Use the critical path method and the critical tasks will have zero slack. Slack is found by subtracting the earliest start from the latest start. Then look for a sequence of critical taks that runs from the start to the fish of the project. This is the critical path for the whole process.

If one activity helps another but it not necessary -- is it a predecessor

It depends. First the "helpful" activity can be split in two: part that helps so much that it must be done first plus a part that is irrelevant. Second you can choose to ignore the help provided in the hope that the shorter schedule will make up for the "helped" not going so well. Third you can choose to include the constraint and assume that the helped task will finish quicker and so the whole project finishes faster. In each case CPM will help to clarify what you need to do.

Planning Smell -- Indecisiveness

A plan that has a decision in it, can not be handled by CPM and is a risky plan. Take whatever actions you can to reduce the risk as early as you can. For example, include activities to gather data to make the decision and schedule them early. Then revise the plan. For example

---

1. It is not clear what algorithm might solve a problem in a program.
   
   1. Negotiate with management for more time.
   2. Start a special project to research and develop several prototype algorithms.
   3. In parallel: research alternative designs to avoid problem entirely.
   
   

---

Story -- My Final Year Project

In my final year project the CPM diagram had a decision box in it I was tasked to use a particular algorithm. I didn't know if it would work or not. I expected it to but it was an untested idea of my adviser. In fact, it was still failing when I had to stop and write up the project. Moral: Forward planning must be mixed with the masterful management of the unexpected.

This means that you can do any amount of planning but you also have to be prepared to handle the surprises that are going to happen in any interesting project. The job of management is to be ready for them and to demonstrate "masterful" handling of them. Being ready, means including some "slack" in the plans.

Reminder -- you should tackle the risky parts (unknowns, new things, ...) first. Early steps should be set up to resolve doubt.

Management is about controlling costs, schedule, quality and functionality. Management is all about people. Learn people skills! You always need management but in small projects it is self management. Management has many facets. Here I cover: Complexity, Meetings, Success vs failure, Control, Configuration Mangagement, Lists, Reading.

Complexity

1. As a team grows the problem of controlling grows as the square of the number of people.
2. Complexity: O(number_of_parts^2)
3. Handling more than half-a-dozen people directly reporting to you is a crazy making task.
4. So you start to make a hierarchy, reports, paper work, ...

. . . . . . . . . ( end of section Complexity) <<Contents | End>>

1. For parts of managment:
2. Management = plan + organize + lead + control.
   
   
   1. Planning and Organizing is feed forward.
   2. Controlling and Leading is feed back.
   
   
   • You need all four of the above skills. Choose how much of each is right for each project. One size does not fit all.
   • Planning is about avoiding future crises.
   • For most people in software development it is better to set goals and provide resources rather than define precise steps. Programmers like to program their life.
   • Large and/or long projects are much harder to plan, estimate, control, and make successful.
   • All the four components are continuous: you plan on day 1 and on day 100...
   • Organizing is about setting up a more or less formal system that lets the team complete the project: communications, data, etc. Think in terms of a DFD of your team!

   Meetings

   1. A meeting must have a purpose. If not -- cancel it.
   2. Invite just the people who fit the purpose. Make sure they know what to bring.
   3. Plan the agenda, handouts, food, drink,...
   4. Organize the room. Boards, walls, equipment, ...
   5. Finish when purpose is achieved.
   6. Don't forget to schedule the next meeting (if any) at the end.
   7. Finish by making sure people know the "deliverables" -- what they bring to the next meeting.

   Success or Failure

   1. Success: All projects succeed (say the people who did them).
   2. More large projects fail (say the clients).

   3. Common reasons for failure
      • Business issues
      • Budget issues
      • Schedule issues
      • Mismatch between business goals and project deliveries:
        • The tail wagging the dog. When technology drags the enterprise away from what it needs to succeed.
        • When requirements change faster than you can handle them projects fail.
   4. Aim to grow software rather than create it in a single "big bang". If at all possible, plan to deliver big projects in small increments. Each is a working and high quality piece of the whole.
      
      1. Less risk, better estimates, better results and morale.
      2. Easier to meet client's needs in small safe steps.
      3. Aim for faster stakeholder feedback and making course correction. You do not drive to work with your eyes closed...
      4. Don't forget to keep control of the flow of requirement changes. Most organizations/projects set up a "Change Control Board" -- -- --(CCB)
         to make sure that the most critical changes get through. Again think of this as part of a DFD.
      5. Requirements are going to change.
      6. Do the risky requirements first.
      
      
   5. Do not treat system development as a manufacturing process. It is nearly always research and development.

   Control

   1. No control without communication, and no communication without control (Patricia Botting's third law)
   2. Quality is improved by reviews, inspections, walkthroughs, etc.
   3. How do you communicate the artifact and the quality review information: paper, face-2-face, or Electronic?
   4. Fast feedback makes a big difference. "Captain: there is a big iceberg ahead!".
   5. In all my projects (senior, intern, ind. study, or graduate) I ask for a short informal report: email, phone call, or meeting every week or every other week.
   6. Status Meetings. Can get ugly!
      Stand up scrum meetings every morning?
   7. Status Reports may help managers but they delay real work. Make sure the value is obvious.
   8. Draw a DFD of your development process and check for smells.

   Controling access to Artifacts

   With more than 4 or 5 people in a team working on the same artifacts -- especially code -- you need a system that stops two people modifying the same file in parallel. Without a control system the last person to save the artificate desroys all the work done by the rest of team. With a Control system only one person can work on a file at a time. People check out the the artifact, work on it, and the check it in.

   Version Control and Software Configuration Management

   With complex projects it becomes difficult to keep track of different versions -- especially when different programmers are working on different components/modules/classes at the same time. The moment you have more than 3 or 4 people working on a set of documents you need to stop two people working on the same version of an artifact at one time. Your also need to control the different versions and different modules in your software. There several tools to help control this. Currently (2007) Subversion is the system of choice. But in the past UNIX users used RVS, SCCS, etc.
3. SCM::="Software Configuration Management",

   Notice: you don't need a complex "Heavy weight" SCM system for simple projects with few people and small scopes. You need it for medium to large projects.

   Configuration management ( CM ) is needed from day one in a project of any realistic size. Each document or artifact has many versions and you need to know which one to use... For programs you can easily get into "DLL Hell" just because the user is using the wrong version of a library. Even DFDs, manuals, standards, and other types of documents will need SCM.

   In all SCM systems a strict regime is enforced. To work on an artifact you must:
   

   1. Check the current version out. You may have to wait for another person to check it in before you can do this.
   2. Make changes and make sure they are good.
   3. Check the artifact back in again (letting some one else work on it).
   
   Some SCM systems allow you create branching versions and integrate them into different versions of a growing system. Good SCM systems keep a log of all the activity in the controlled artifacts.

   Useful Lists for Managers

   1. Four_phases_for_managing_a_project::=following
      
      1. initiation
      2. planning
      3. executing
      4. closedown
      
      
   2. initiation::procedure=establish the following
      
      1. Select and brief an initiation team.
      2. Set up good relationships with customer/client.
      3. Create an initiation plan.
      4. Set up management procedures.
      5. Create the environment (physical and electronic).
      6. Launch the project workbook.
      
      

   3. SSR::form="System Service Request".

   4. work_book::artifact=following
      
      1. Overview
      2. Initiation plan and SSR
      3. Scope and risks
      4. Management procedures
      5. Data descriptions
      6. Processing description
      7. Team correspondence
      8. Statement of work
      9. Project schedule
      10. Online copies of definitions and diagrams
      
      
   5. planning::=following
      
      1. Establish scope, alternatives, feasibility
      2. Divide into manageable tasks
      3. Resources: estimates and plans
      4. Preliminary schedule
      5. Set up communications
      6. Define standards and procedures
      7. Identify and assess risks
      8. Preliminary budget
      9. Baseline project plan
      
      
   6. executing::=repeat following
      • Carry out baseline plan
      • Monitor Progress vs plan
      • Make changes to plan
      • Maintain the workbook
      • Communicate project Status

   7. closedown::procedure=following
      
      1. Close down project
      2. Post mortem review
      3. Close customer contract
      
      

   . . . . . . . . . ( end of section Useful Lists for Managers) <<Contents | End>>

   Readings on Management

   You won't be managing a team straight out of college! This course just touches on the high points. CSCI455 and/or CS655 (Software Engineering) goes further. But before you get promoted to management you will need to learn more. An enormous number of books have been written on management. Some of these are about managing software development. Before you start your first project as manager please read so I have added a list of readings that will help. Some of these are available on line... but most are books you might want to have on the bookshelf in your office when you get promoted to managing people.

. . . . . . . . . ( end of section Management) <<Contents | End>>

Questions

Is there a point where the accumulation of new requirements add up to a new project

Yes. I use the data models (later in this class) to spot additional requirements could be best tackled as a new project. Another trigger is the obsolescence of a part of the platform for a project that depends on a particular platform. For example, the aging of our mainframe makes it inevitable that we will need a replacement for the applications that run on it.

What is a Change Control Board for

It is a group of people who decide whether a requested change in a system is carried out, or delayed, or put with others into a special project, or thrown out.

What is the most common reason for project failure.

Size. There is a clear pattern in the literature (and the news) that shows larger projects failing more often than small ones. There is also the related problem that a project may not be given the resources that it needs for its size. This also leads to failure in many cases.

Does removing people from a project speed up its development

It depends on the person removed:-) More seriously: no. Brookes' Law is based on the time to train people in the domain and the software so far developed. Getting rid people does not "untrain" them. It wins no time.