This blog will introduce some keys concepts in project planning aimed at product designers and engineers, with limited experience of the subject, with a focus on the application of traditional “Waterfall” and more recent Agile methodologies to hardware design and development projects.
Project & Portfolio Management a Definition
The following definition comes from the Association of Project Management (APM).
Project management is the application of processes, methods, skills, knowledge and experience to achieve specific project objectives according to the project acceptance criteria within agreed parameters. Project management has final deliverables that are constrained to a finite timescale and budget.
A key factor that distinguishes project management from just ‘management’ is that it has this final deliverable and a finite timespan, unlike management which is an ongoing process. Because of this a project professional needs a wide range of skills; often technical skills, and certainly people management skills and good business awareness.
Definition from APM Body of Knowledge 7th edition
We can interpret this in simple terms as, “the coordination and management of a budget and resource to deliver an agreed output within an agreed time to an agreed specification.”
Project Portfolio Management (PPM) is the coordination of multiple projects within an organisation. An important consideration in PPM is balancing resource, such as annualised budgets, skilled resource or capital facilities, across multiple projects to deliver the overarching objectives for the organisation.
Project Management Methodologies
Methodologies refers to the approach, or framework, used to deliver the project. Remembering that the project team has been created to deliver a key objective, such as a new product to market, think of the method as a Standard Operating Procedure (SOP) to ensure consistency and create a common understanding for how the team shall deliver the objective.
Waterfall is the most established and recognised methodology and refers to a linear, sequential approach to product development. It divides the process into distinct phases such as requirements gathering, design, development, testing, deployment, and maintenance.
Agile refers to an iterative approach emphasising collaboration and adaptation. It divides the product development phases into short iterations called sprints (typically 2-4 weeks).
Within the Agile “umbrella” there are various philosophies that seek to provide an overarching set of rules for the project team, two of the most common are Scrum and Kanban. For those most familiar with the Waterfall methodology one of the most confusing aspects when working with Agile methods may be the terminology associated with these rules (or rituals).
Lean refers to the application of tools and processes to optimise the management and delivery of the project, aiming to identify and eliminate waste and rework. Lean methodology can be applied to both Waterfall and Agile ways of working.
All approaches have merits and drawbacks so it’s important to assess the method you will adopt against the context and complexity of the project in hand.
Organising Project Work
All plans are typically organised in a hierarchical structure referred to as a Work Breakdown Structure (WBS) which allows a project or programme to be divided into discrete groups for programming, cost planning and control purposes. In Agile the WBS is delivered through the use of Features, User Stories and Tasks.
Using the product lifecycle phases, or stages of the design process can be a good starting point, and then depending on the complexity of your product you may choose to also organise using the Product Breakdown Structure (PBS) which essentially relies on the physical and functional decomposition of the product.
Communication
Ask yourself who are the stakeholders you need to communicate the plan to and discuss the level of detail they would like to see and how often. Always consider your audience, you could produce a ‘Plan on a Page’, which is a high level summary showing key milestone and critical path providing a snapshot of the project status to save readers ‘switching off’ or ignoring your schedule altogether.
Project Management Software Tools
There are a plethora of project management software tools out there, from Microsoft Project and Primavera P6, to Jira and Azure Boards. My advice would be to use an approach that is proportionate to the size and complexity of your project. I have seen people use pen and paper and deliver the required outputs, within budget and ahead of schedule, and conversely I have seen a disproportionate amount of time and cost spent implementing complex enterprise level software tools that deliver nothing but ambiguity and confusion.
Agile for Complex System Engineering Programmes
As previously discussed all projects require an overarching schedule structure to layout and sequence objectives and dependencies. The benefits of Agile come in the associated simplification of that schedule as the tasking is devolved down into the Agile project management tool, but complementing this with an overarching Waterfall schedule is useful to show the impact any delays in meeting sprint targets of overall project objectives. The graphic below illustrates how the planning levels may look in a hybrid “Agile Waterfall”.
The above may manifest as shown in the example below, which takes the Level 1 and 2 WBS from the overarching Waterfall schedule and aligns the deliverables to User Stories, that represent the tangible outputs. These may be technical reports, design schemes, calculations or verification tests that feed into the compliance evidence that demonstrates your product can deliver the requirements. The tasks represent the detailed steps need to deliver the User Stories. The mantra of Agile is quite prescriptive in regard to the sizing of User Stories and Tasks, in practice I would suggest being overly prescriptive can distractive from the technical aspects of the work and different individuals cope with this in different ways. This is where experience, judgement an coaching can be invaluable both at a technical and programme management level.
I hope this blog has been of interest and if you feel this may be an area where you need support, or a fresh perspective, please get in touch. I have witnessed first hand the benefits of the approaches outlined above and am always happy to have a conversation that could be of help.