Projects deliver change to an organization. Outside of normal routine, projects are designed to accomplish a particular goal, often involving people who don’t usually work together. Project management professionals carve out time and space to allow a temporary team to reach its objectives within clearly agreed measures of time, cost and scope.
While this might sound like a successful outcome, there are further success factors along the timeline:
- Project is within time, cost and scope (short-term goal)
- Project brings value to the customer by addressing the original “pain”
- Project is adding long-term benefits to business success
- Project prepares company for the future by being scalable and/or allowing other elements to build on it (very long-term view)
Allow me to support you on a temporary basis with bringing projects off the ground, back on track or fill in while the designated project manager is recovering.
I have seen multi-million-dollar projects being declared a success by IT while business never fully implemented it. Projects, where time and budget were extended by more than factor 2, yet the organization had no pre-determined breaking point. There are many factors adding to project failure and they can be found on every level and in every stage of a project. As Schweizer PM, I will do my best to avoid and mitigate any of the following issues:
- Unclear project governance
- Missing requirements
- Requirement gaps in vendor selection
- Fuzzy scope / outcomes not defined
- Unrealistic timeline
- Moving target
- False/missing reaction to risk occurrence
- Missing customer need
- Too much risk in the project overall
- Project duration too long
- Requirements are not clear / not clearly understood
- Budget cuts during project flight
- No transparent communication
Tree swing project (source: anonymous)
Different project management standards such as CMM (Capability Maturity Model), PMBOK (Project Management Body of Knowledge), PRINCE2 (Projects in Controlled Environments), IPMA (International Project Managers Assosiation), HERMES (Swiss Federal Administration), Lean (waste reduction in project context) or LogFrame (logical framework, popular in international development organizations) are required in different contexts, yet – in essence – they all cover the relevant phases initiation, planning, execution, control and closing of a project. The same principle applies to Terms of reference (TOR), project definition, project scope statement or project charter – all are different terms for the same thing: the purpose and structure of a project.
Methods like Waterfall or Agile depend on the scope and environment of a project. Waterfall could be applied to virtually any type of (IT) project. Agile (with methodologies such as SCRUM or Kanban) requires specific conditions to be in place to be possible but is not applicable to certain projects – especially those of a large physical nature.
Breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one
- Agile is suitable if a team can carve out time to work together intensively, customer requirements only emerge over time and a minimum viable product can be defined, which is successively expanded to a full scope of funcionality
- Waterfall is suitable for large projects, where full requirements can be gained through input from many stakeholders (and from writing many documents) before starting a project.
Iterative cycles of product development and product launch will allow the product to evolve from minimal viable product to full functionality.
Lean Product Development
The key of this method is the focus on meeting customer’s needs and quantifying the fit. In this regards this method is somewhat related to the Lean Six Sigma method to improve existing processes. Iterative design cycles (“agile sprints”) will bring a minimal viable product (“MVP”) to a full functionality while allowing specifications to evolve and change without a heavy toll on nerves and project budget. This helps to avoid many pitfalls of the old waterfall model, where everything had to be known and documented before software developers would start their work. Where IT would shake their head about new user requirements and point to a change management process that had no funding yet.
Lean Development has the tools to understand what the customer would pay for, define use cases (“user stories”, “personas”), allow the user to click through prototypes (“wireframe” or “mockup”) and canover time develop a realistic idea of how much functionality can be delivered in each design cycle. The journey with this agile setup is more intense, more open, more quality-oriented, more suitable for changing market requirements and more focussed on delivering value to customers fast. The downside of a lean or agile approach for the project sponsor is less tangibility of the final product, less documentation and more involvement to take decisions throughout the project than in a waterfall approach. I recommend to list non-functional requirements completely and before starting the agile project. They might impact the basic architecture which is harder to change in full project flight. To find out more, check out the vast resources available online by searching for “waterfall vs. agile”.