3. A Project Management Primer ¹

Scope Triangle

• Time, Cost, Quality
• Scope creep is the almost unstoppable tendency a project has to accumulate new functionality.
• the art of project management is to make decisions quickly.

The Critical Path

• the critical path of a project, is th the minimum set of tasks that needs to be completed.

The Mythical Man Month

• adding people to a project doesn’t speed it up.
• the increase in speed is not directly proportional to the amount of resource added.
• The main reason for this is the increased complexity of communications which results from adding more people.
• Small autonomous teams are more efficient than large bureaucratic ones,so divide your project up into manageable chunks and let each group work within some kind of defined boundary.
• If you want to add people to a project, you had better plan carefully plan how those people are introduced into the team, there will be a lag before they become productive and even be a drain on the productivity of other members of the team.
• instead of adding more people, try to ask for more time; or cut functionality.

Scope, Goals, and visions

• Scope is a general term to describe everything that your project encompasses, everything that must be achieved for the project to be complete.
• vision is a single encapsulated idea which defines the aim of the project.
• If you can’t state the aim of your project in a single sentence, then it’s probably not a project. it is probably an idea for a business or possibly a way of life.
• Goals are slightly lower-level and more specific than the vision. . Typically goals are set out by customers or by a business and define how the success of the project will be achieved.
• Note that the terms scope, vision and goal are largely interchangeable.
• While further steps in the project planning aim to be more and more specific the initial goal should be broad enough to encompass the whole project.
• The Vision as Inspiration
• Goals as a Filter for Requirements

The Project proposal

• Project proposal is a document that states the highest level goals in a project. It outlines the overall business goals and vision for the project as decided by the customer or client.
• it is not long or overly detailed, instead it is an outline, details come later.
• it is good to think about Return on Investment (ROI) when writing a project proposal.

Requirements

• Requirements specification is the process of refining the goals of a project to decide what must be achieved to satisfy the clients.
• Functional requirements are the obvious day-to-day requirements end-users and stakeholders will have for the product.
• Non-functional requirements are the less obvious requirements that are not directly related to the product’s functionality. includes:
  • performance
  • usability
  • reliability
  • security
  • financial
  • legal
  • operational
  • specialist: eg. medical, legal, financial, etc. these kind of projects needs to be done by people who are experts in the field along side engineers.

Stakeholders

• Stakeholders are an integral part of a project. They are the end-users or clients, the people from whom requirements will be drawn, the people who will influence the design and, ultimately, the people who will reap the benefits of your completed project.
• always involve stakeholders in the project at all stages this will:
  • create self-correcting feedback loops.
  • increase confidence in the project.
• types of stakeholders:
  • Executive: managers, guys who pay the bills.
  • End-user: the people who will use the product.
  • Experts: people who are experts in the field that the product may needs their input.

More Requirements

• Requirements capture is the process of harvesting the raw requirements of your stakeholders and turning them into something useful.
• methods of requirement capture:
  • interviews
  • questionnaires
  • user observations
• Documenting Requirements:
  • you need to document the requirements.
  • stakeholders may need to sign the requirements document.
  • you need to justify your architectural decisions in the requirements.
• requirements needs to be SMART:
  • **S**pecific
  • **M**easurable
  • **A**chievable
  • **R**elevant
  • **T**estable
• Sometimes classification of requirements is made using the MoSCoW rules:
  • Must-haves are fundamental to the project’s success
  • Should-haves are important, but the project’s success does not rely on these
  • Could-haves can easily be left out without impacting on the project
  • Won’t-have-this-time-round can be left out this time and done at a later date

Traceability

• traceability includes requirements specification and the technical specification.
• the traceability can be extended to the testing phase and it can be shown in test reports, as which test validates which design element and, consequently, which requirement.

Project Plan

• The purpose of a project plan is to maintain control of a project.
• The Elements of a Project Plan:
  • What is to be done
  • When it needs to be done by
  • Who is to do it
  • How it is to be achieved

Scheduling

• Principles of Scheduling:
  • Never, give off-the-cuff or unconsidered responses (don’t commit to something you can’t deliver): don’t give dates on the fly, always ask for time to think about timing then answer later
  • Eliminate uncertainty wherever you can: the more specific the requirements are, the more accurate the schedule will be.
  • Build in plenty of contingency to cope with variation: promise low / deliver high, plan for gaps in the schedule, that you cal later allocate if delays occur.
  • Pick the right level of granularity: if you decided day-by-day updates, your tasks must be chunked down to the day level (every task must be of a size that cane be finished in a day). same goes for weekly updates, tasks must be chunked down to the week level.
  • Schedule for the unexpected
• The Format of Project Schedules:
  • Milestones:
    • a sequence of events in time.
    • milestone represents a significant amount of the project.
    • always add 10-20% of time to the schedule to account for unforeseen delays.
  • Gantt charts:
    • simply, a visual representation of a schedule.
    • time is represented along a horizontal axis and tasks listed down the left-hand side by a horizontal bar.
    • Milestones are usually represented by single points or diamonds.
    • Dependencies between tasks are also shown as linked arrows.
    • 

Costing and Budgeting

• The concept of prudence – you should be pessimistic in your accounts.
• The accruals concept- revenue and costs are accrued or matched with one another and are attributed to the same point in the schedule (every time you pay an invoice, think of ALL previous payments as accumulating costs for this thing).
• tangible costs of a project: list all items of a project (including manpower) and their costs next to it, then sum it up. (you still need to think of the intangible costs).
• tangible costs:
  • capital expenditure (CAPEX): the cost of buying equipment, software, buddings, etc.
  • lease costs: the cost of renting equipment, software, buildings, etc.
  • staff costs
  • professional servicesL the cost of hiring external consultants, contractors, lawyers, accountants, etc.
  • supplies and consumables
  • one-off costs: the cost of one-time purchases, such as software licenses, staff trainings etc. these happens on irregular basis.
  • overheads: indirect costs, such as office rent, utilities, etc.
• Intangible costs:
  • opportunity cost: the cost of not doing something else.
  • risk: the cost of uncertainty.
  • time: the cost of delay.
  • quality: the cost of rework.
  • morale: the cost of stress.
  • reputation: the cost of failure.
  • cost of quality: the cost of quality.

Risk Management

• talk about risks with your team in regular meetings. try to find ways to mitigate the risks.
• for large projects, you may need to hire a risk management officer.
• Risk profiles:
  • Risk to a project can be measured on two major axes: likelihood of failure and impact of failure.
  • 
  • critical risks are those that have a high likelihood of failure and a high impact of failure, they will stop the project. must be dealt with immediately.
• Resolution of risks:
  • Research: risk is not fully understood, so you need to research it.
  • Accept: risk is unavoidable, so you need to accept it.
  • Reduce: risk is unacceptable, so you need to reduce it.
  • Eliminate: risk is unacceptable under any circumstances, so you need to eliminate it.

Change Management

• Change management is a way of assessing the implications of potential changes and managing the impact on your project.
• you must put a clear process of requesting change in your project, in a way that everyone in the team are 100% aware of it.

Managing People

• Negotiation:
  • it is hard to negotiate with people in tech.
  • aim for achieving consensus, and avoiding conflicts.
  • fundamentals of negotiations:
    • understanding: understand the problem under discussion, understand the other party’s position, understand the other party’s needs.
    • empathy
    • trust: people compromise more when they trust each other.
    • contribution: during the negotiation, each party should contribute to the solution, silence is not an option.
    • consensus
• Building a team:
  • trust: be open and honest with your team.
  • equality: be fair and even-handed.
  • never criticize: criticize the work, not the person.
  • do not land problems on a shoulder of one person, pull up the team and present the issue, the team will highly likely collaborate to solve it.
  • you need to be loyal to your team, and they will be loyal to you. always defend your team, even if they are wrong.
  • learn to delegate: you can’t do everything yourself, you need to delegate tasks to your team.

Implementation

• Acceptance Testing:
  • you need to accept test the product before handed it over to the client to do his acceptance testing.
  • do acceptance testing on a regular basis, not just at the end of the project.
• Release Control:
  • version number of identifier of a release is a vital part of the release control process.
  • track the dates of the release.
  • track the purpose of the release: maintenance, new features, bug fixes, etc.
  • if the product has multiple subsystems, you need to track the release of each subsystem separately.

Maintenance and Upgrades

• keep product documentation and plans in hand for future reference.
• plan your upgrades and maintenance in advance.

Project Closure

• When things go wrong you shoulder the blame and take responsibility. When things go right the credit goes to the team and rarely do you get singled out for a pat on the back.

References

---

1. Jenkins, N. (2005). A Project Management Primer ↩