Working in a Team
Objectives
Assess project feasibility
- Estimation
- Scheduling
- Risk
- Should you commit to a project?
- Before committing, conduct a study to inform a go/no-go decision
- Result may be a proposal or lead to a budget request
Produce a project plan
- A detailed project plan is critical
Feasibility studies are difficult
Must grapple with uncertainty
- Unclear scope
- Uncertain or hard-to-quantify benefits
- Rough estimates of resource requirements and timetable
- Technical approach may not pan out
- Organizational changes may be required
- Opportunity costs
Rely on judgement of experienced people
- Early mistakes are the most costly
- Need to advocate to build support
- But beware risk distortion, ulterior motives
- Example: US government agency
Discussion
- Designate one person as a note taker/final reporter
- Which methodology is most appropriate for a large, complex project with incomplete requirements?
Things to consider in a feasibility study
Overview
- Scope
- Approach
- Methodology
- Resources
- Schedule
- Risks
- Alternatives
Scope clarification
- Define the boundaries of the system
- List of included features
- List of excluded features
- List of dependencies
- List of current systems being replaced
- Confusion over scope often leads to client dissatisfaction
- Should also review existing systems (including competitors’)
Technical approach
- Proposed system must be technically feasible
- Estimates of scale (number of users, volume of data, rate of transactions)
- Identify features that require research (no standard solution) or new team expertise (domain-specific knowledge, advanced techniques)
- Analyze a viable design to estimate resources, schedule
- Tentative system architecture (data storage, UI context, deployment infra)
- Approach used by final product may be very different
Estimation
- Essential skill for efficient planning
Discussion
- Designate one person as a note taker/final reporter
- Fermi problems:
- Tips: first identify dimensions of answer (dimensional analysis)
- What is the sustained half-duplex bandwidth between Ithaca and NY Tech of a UPS truck full of hard drives?
- How many Raspberry Pi computers would be required to serve as a distributed cache for a global reverse phone book?
Estimation for scheduling
- Estimating task duration is very difficult, but can be improved with feedback
- Estimate effort of task before starting
- Keep a log of time spent on each task (design, documentation, implementation, testing, review)
- Compare log to estimate when closing out tasks
- Keep a log of time spent on other aspects of project (meetings, training, reports, reviews)
- Do not evaluate effort until task is 100% complete
- Large gap between “almost done” and “done”
- Documentation
- Tests
- Cleanup
- Review
- Beware Parkinson’s Law: “Work expands to fill the time available”
- Don’t neglect startup time
Agile velocity
- Dartmouth example: projects consistently took 30-40% longer even when requirements were well understood.
- Additional tasks discovered
- Some tasks must be iterated
- Personnel have other commitments
- Schedule conflicts
- Decouple effort from time
- Estimate effort required for task in relative units (e.g. “story points”)
- Tally the effort units completed by the whole team in one sprint: velocity
- Use velocity to select appropriate number of tasks for future sprints; forecast milestones accordingly
Milestones and deliverables
Deliverable
- Work product provided to the client
- Mock-up
- Demonstration
- Prototype
- Report
- Presentation
- Documentation
- Code
- Release of a system or subsystem to customers and users
Milestone
- Completion of a predetermined set of activities
- Delivery of a deliverable
- Completion of a process step
- End of a sprint
- Reaching a testing target
- An internal goalpost, useful for monitoring progress against the schedule
Initial preparation steps
Outline plan
- Your first report requires an outline plan
- Preliminary timetable
- Process steps (or sprints)
- Milestones (including deliverables)
- Decision points
- Interactions with and dependencies on external parties
- Plan should be reviewed, refined, revised regularly
Scheduling activities
- Inputs:
- Duration
- Dependencies
- Resources
Activity networks
- Gannt charts
- In combination with milestones
Risk management
- Identify risks
- Brainstorm what could go wrong
- Analyze risks
- Determine likelihood and consequence
- Prioritize based on “risk”
- Plan
- Avoidance: reduce likelihood
- Mitigation: reduce consequence
- Contingency: “Plan B”
- Monitor
- Feasibility studies and project plans should be written
- Well-written, well-presented – review entire document
- Short enough that everybody reads it
- Long enough that no important topics are skipped
- A report that is not read and understood is not useful
- Keep in mind:
- Team availability, team skills
- Time constraints
- Equipment and software
- Start-up time = Client availability
- Scope (not vague, not too ambitious)
