• Input of Project Management and Planning
• : Eisenhower -- Planning is everything but the plan is nothing.
• : Story -- How Fast can you build a house?
• : Joke
• : Brookes's Law: Adding staff to a late software project makes it later.
• : Personal Planning
• : Team Planning and Organization
• : Enterprise Level Planning
• : Management
• : Estimating and Planning
• : Tools: MS Project. Visio. UML
• : Hints with planning diagrams
• : Planning Smell -- Indecisiveness
• : Story -- My Final Year Project
• Questions
• : Can we face a critical path at the start of a project
• : What is the best way to estimate the time to develop software
• : 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
• : Activity on node vs Activity on an arrow
• : Why did I stop using PERT notation
• : How do calculate start and finish times
• : How often are Scrum meetings
• : 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
• : Do the Readings on Management make me an OK manager
• Discussion topics
• Exercises on Critical Path Methods
• Quiz 5 on Critical Path Methods
• Abbreviations

Input of Project Management and Planning

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

Story -- How Fast can you build a house?

The record is one day. [ 1042 ]

Moral: Careful planning can save a lot time doing.

Joke

[ Hofstadter%27s_law ]

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

See MMM below. So..... get enough people first.

More general -- software development is more like research than manufacturing so some traditional planning techniques tend to lead to failures.

Personal Planning

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.

Team Planning and Organization

Enterprise Level Planning

Management

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, ...
1. Management is about controlling costs, schedule, quality and functionality.
2. You always need management but in small projects it is self management.
3. Management = plan + organize + lead + control.
   
   
   1. Planning and Organizing is feed forward.
   2. Controlling and leadership 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.
   • Better to set goals and provide resources rather than define precise steps.
   • 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!?
   • Management is all about people. Learn people skills!

   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.
        • Requirements drift. When requirements change faster than you can handle them.
   4. 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 clients needs in small safe steps.
      3. Faster stakeholder feedback and course correction.
      4. Requirements are going to change anyway....
      5. Do the risky requirements first.
      
      

   5. Do not treat system development as a manufacturing process. It is Research and development.
   6. Aim to grow software, bugs and all.

   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?!? See [ Scrum_%28development%29#Scrum_meetings ] or [ Craig Larnman ] below for details.
   7. Status Reports may help managers but they delay real work. Make sure the value is obvious.
   8. Draw a DFD of your process and check for smells.

   Software Change control

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 a part of a DFD.

5. Your also need to control the different versions and different modules in your software. 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. There are several pieces of software that can help: RVS, SCCS, Subversion, ....

6. SCM::="Software Configuration Management", [ SCM ]

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

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

Estimating and Planning

1. Time and cost 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. Break down a complex piece of work into simpler steps.
3. Look for steps that are novel -- these are risky and should be done early rather than later.
4. Work out what steps must be complete before other steps can start. "predecessors".
5. These are called a "Work Breakdown Structure" -- -- --(WBS)
   
6. They can be shown as activity diagrams or other charts (below). This is wise.
7. 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. We add up the durations to figure the time to completion. Software development has lots of sequences: write code before compiling and make it compile before you you test it.

   Here is an example of a parallel structure.

   

   The time to complete is the maximum of the two times.

   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.

   ---

8. Here is an example for 1 week of eXtreme Programming.
9. This shows a WBS as a table.
10. Note: times 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)
    

11. I've found that tables like this are an easy way to document a WBS but they are error prone. 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.

12. Example for you: How do you make coffee.

    Example -- Implementing my PICT system.

    During my Ph. D. I created a graphic package 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.

13. All methods use what mathematicians call "directed graphs" -- see Math272.

    Special Notations

    Gantt charts

    Plot time on the x axis and tasks down the y axes. [ Gantt_chart ] [ search?cat=img&cs=utf8&q=gantt+chart&rys=0&itag=crv ] I only use these when I can get them drawn for me. 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.

    PERT

    [ PERT ] I don't like the PERT notation of arrows for activities and bubbles for events because activities often have many prerequisites etc. I was taught this in the 1960's but rapidly moved away from it. However it has a very useful formula:
    1. Expected := (Best+4*Most_Probable+Worst)/6.
    2. Use this formula to get the durations of activities in CPM.

       CPM

       [ Critical_path ] I like the method and have used the common notation until recently.
       • Task data: id and name, duration, earliest start, earliest finish, latest finish, latest start.
       • Slack and Critical Activities are calculated and added to the boxes.
         Table

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

         
         (Close Table)
         
       • Predecessor-Successor linked.
       • All tasks predecessor tasks must be done before all successor tasks
    3. Networks of tasks.
    4. Example: BS Program!

    The Critical Path Algorithm

    
    The algorithm assigns four times to each task:
    Table

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

    
    (Close Table)
    Algorithm:
    
    1. Forward: earliest start is the maximum of predecessor's earliest finishes.
    2. Backward: latest finish is the minimum of the following latest starts.
    3. Slack = earliest - latest.
    4. Note: Float = Slack.
    5. Critical is true if and only if Slack is 0.
    
    
14. 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)
    

Tools: MS Project. Visio. UML

You can use pencil and paper, Visio, and Dia. In a group use a board -- it's fun.

MicroSoft have a tool called MS Project. Also see: [ List_of_project_management_software ]

Use UML Activity Diagrams for planning development processes. You can do CPM easily in the UML.

• Task = activity
• Draw explicit parallel symbols [ UMLCPM1.gif ]
• Attach a duration to the activities.
• Attach earliest and latest times to transitions. Calculate them using the CPM algorithm above. [ UMLCPM2.gif ]
For example, see [ UMLCPM3.gif ]

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 no where.
4. Watch out for events/predecessors that are redundant before you do the CPM.

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 schedule the decisions early and do another plan after the unknowns have been resolved. 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 prototype algorithms.
   3. In parallel: research alternative designs to avoid problem entirely.
   
   

---

Story -- My Final Year 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.

Questions

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

All WBS have a critical path and it always connects the start to the end of the project. It is a property of WBSs!

What is the best way to estimate the time to develop software

There are some standard techniques that are covered in CSCI455 (Software Engineering) -- See [ COCOMO ] and [ Function_point ] for more, they are not part of this course.

All good methods are based on relevant previous experience and data plus breaking down the project into the parts.

Which do I prefer: Visio or Dia

Somehow I like Dia better because it is not pretentious and is free. I dislike paying for a program like Vision 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.

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.

Activity on node vs Activity on an arrow

The PERT notation associates task and activities with an arrow. So when there are more than one predecessor activity you need to add extra dummy arrows/activities/task to show the dependency. This is a bit kludgey when compared to make arrows "events" indicating the completion of activities in my humble opinion.

Why did I stop using PERT notation

See above.... I'm still doing CPM for just about everything in my life.

How do calculate start and finish times

Use CPM!

How often are Scrum meetings

Every day, in the morning.

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.

Do the Readings on Management make me an OK manager

They are better than nothing. They inject some experience and know-how that will help. The main blockage to you being an OK manager in the long term, is your own personality.

Discussion topics

1. In how many ways is developing software like gardening?
2. In how many ways is developing software like a medical operation?

   Exercises on Critical Path Methods

   1. (CPM Exercise): Do a CPM on a given network.
   2. (Planning exercise): Given project description(in handout) of tasks and durations do a CPM.

   3. In class [ cpmEx.html ]

   Quiz 5 on Critical Path Methods

3. (Q5): Demonstrate doing CPM

   ---

   1. Given a list of tasks with durations and prerequisites:
      
      1. draw a CPM network(5 pts).
      2. calculate the earliest start and finish times(4 pts).
      3. calculate the latest finish and start times(4 pts).
      4. highlight the critical path(2 pts).
      5. errors in arithmetic (-1 pt each).
      
      

   ---

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

Abbreviations