Software Development Project Management

Starting a Project

Understand the following:

  • Who is the one person at the top of it all? If it all fall apart, who’s neck is on the block (also in the context of who you are working for).
  • What is the project name? Every project (and programme) needs a name so everyone can easily identify and refer to it.
  • What are the success metrics for completing the project?
  • Are there any hard deadlines that need to be met?
  • Identify and meet:
    • Sponsors
    • Stakeholders (clients)
    • Suppliers
  • Who are the users?
  • What are the stakeholder reporting requirements?
  • What are the stakeholder expectations?
  • What is the budget?
  • Identify timelines, deadlines and schedules.
  • Identity deliverables.
  • Identify and gather required resources:
    • People
    • Equipment
    • Infrastructure
    • Working location(s)
  • Initiate scheduling.
  • Identify and setup tools for:
    • Document sharing and management
    • Communication (email, chat)
  • Gather email addresses and phone numbers.
  • Identify reporting expectations.

Write everything down.

 

Day-to-day

Track:

  • Expenditure tracking
    • Staff
    • Resources & Equipment
    • Services
  • Progress
  • Adherence to the schedule
  • Risks
  • Resource allocation
  • People (resource) availability

Do:

  • Schedule meetings.
  • Schedule periodic/recurring meetings.
  • Stakeholder progress updates.
  • Manage stakeholder expectations.

 

Scheduling

  • Availability of people:
    • Assume a maximum 75% output (e.g. 8 hour work day = only 6 hours is “producing” output).
    • Weekends
    • Public Holidays (local and remote workers).
    • Holidays/Leave
    • Sickness
    • Part-time work load
  • Sprint duration
  • Output cadence
  • Stakeholder expectations
  • Allow for things to go wrong. They always do.
    • No project is just a happy path.
    • Schedule for completion at least 25% earlier than the expected end date.
    • Prioritise tasks as “Required” and “Backlog”. Required get done first. Backlog are nice to have is there is time left.
  • Allow for testing.
  • Allow for rounds of testing and feedback and re-work.
  • Allow for review and rework (refactoring).

 

Risks

  • Access to people (resources)
  • Scope change

 

Things that can go wrong and impact delivery

  • Development environment setup, changes/updates, disasters and downtime
  • Infrastructure changes and downtime
  • Security firewalls
  • Access to external systems and data
  • Sickness
  • Bad tooling/technology decisions
    • Technology was later found to be not suitable
    • A tool or technology is just a complicated bitch to work with and wastes hours
  • Complicated or “fancy” solutions
    • Simple is always best.
  • Incompetent or inadequate developers
  • Changing scope
    • (“Can you just add this small change…”)
  • Team burnout
    • Not allowing enough downtime, relaxation, function.
    • Too much overtime

 

Meetings

  • Scheduling everyone to be in the same place at the same time
  • Agenda
    • What
    • Who
    • Apologies
  • Minutes
    • Expand the agenda
    • Action items (who, what and when)
    • Discussion points (who and what)
    • Next meeting
  • Location
  • Attendees
    • In person
    • Remote (call or video)
  • Equipment

 

Tools: Communication, Files & Project Management

  • Emails – don’t CC everyone on everything.
  • Use a tool for general communications (e.g. Slack or Microsoft Teams).
    • Don’t use basic chat tools like Google Chat or WhatsApp – they are not “rich” and versatile enough for all types of team member or all platforms (mobile and desktop).
  • Use a tool for central storage and sharing of files.
    • Reduce email attachments and file versions.
  • Use a tool everyone can access for project management and task allocation (e.g. Trello, Jira, Azure DevOps Boards, etc).

 

External Influences

  • Availability of external products/data to interface with.
  • Developing for inputs (data and API) without documentation or knowing technical/data structures.

 


The key requirements of a project manager

  • Be tough. Say no to stakeholders. Push back. Pretect the team.
  • Making decisions
  • Organising people
  • Ensuring delivery on schedule
  • Ensuring scope is appropriate for schedule/target dates.
  • Budget
  • Resource organization
  • Updating stakeholders. Keep stakeholders happy.
  • Reduce friction and confusion.
  • Increase clarify and understanding.
  • Examples:
    Organising a meeting.
    Organising transport to a meeting (5 people, 2 cars, starting from multiple locations = 12 emails)

 


Much of PM is bullshit and busy work. What if there were no computers? How would that change things?

2 questions:

  1. What is project management?
  2. What is absolutely critical to a projects success (from a PM point of view)?

 

What it boils down to:

  • Successfully deliver a solution as requested by the one person at the top of your chain.
  • Deliver within budget.
  • Deliver by assigned deadlines.
  • Ensure all the “resources” get it done.
  • So:
    • Know the project objective.
    • Get everyone involved focused on that success.
    • Make sure it happens on time and budget.