Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Lynda Bourne
Optimizing Project Delivery Strategy
Categories:
Agile
Categories: Agile
| One element missing in much of the discussion around project management is a focus on the key early decisions that determine the project delivery strategy. At the project level, strategic decision-making focuses on optimizing the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won't change the required project deliverables but will have a major influence on how the project is delivered and its likely success. One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholders expectations. Some of the key steps in designing a strategy for success include: • Familiarization with the overall requirements of the project and its stakeholders The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome. Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don't know they need to be engaged at this stage of the project lifecycle. I suggest that project managers and project management offices start focusing more on the project delivery strategy during critical early stages of a project. What has worked or not worked on your projects? |
Learning From Agile
Categories:
Agile
Categories: Agile
| The Agile community has some good ideas to pass down to conventional project managers, including: Customer Engagement While it may not be possible to iterate the building of a piece of machinery, engaging and explaining to the customer in their language--no jargon--what's happening will highlight issues early. If the customer doesn't like something, the sooner you know, the better. One of the key tenets of Agile is to engage effectively with your customer and end-users, understand their needs and problems, and then deliver an effective solution. This requires regular and effective communication, openness and accountability, and a good measure of trust to support robust relationships between the project team and their key stakeholders. It's a pity so many project managers put their energies into fighting the client rather than collaborating. Going Light and Lean Those are hardly new ideas, but they've been embraced by the Agile philosophy for a good reason: They work. Lean was developed by Toyota as a manufacturing philosophy and has been adapted to many other areas. Some of its key principles--such as minimizing unnecessary movement, simplifying process and continuous improvement--have huge potential in project management. Light is focused on the minimizing unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements. Slimming down the project management overhead to its optimal level is probably the easiest way to free up the resources needed to engage your stakeholders more effectively and is definitely supported by the A Guide to the Project Management Body of Knowledge (PMBOK® Guide). For more information, see Light Versus Lean -- Steps to Improve Project Efficiency from PMI's Community Post. |
The Gentle Art of Managing Agile
Categories:
Agile
Categories: Agile
| A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition has nine technical knowledge areas plus the overall integration processes. By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently. Some of the areas that need an Agile approach include: Project Scope Management Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey. Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture. Project Time Management In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability. This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration. Project Cost Management Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance. Project Quality Management This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production. Project Communications Management The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential. Project Procurement Management Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively. More later.... |
The Role of Agile Advocates
Categories:
Agile
Categories: Agile
| This is a continuation of the post Creating Trust in Agile. Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful. Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective? Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed. AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective. The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management. Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology. I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ... Over to you for comment! |
Creating Trust in Agile
Categories:
Agile
Categories: Agile
| Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate. The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership. Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time. The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt. An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end." With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches: We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value. We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way. In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline. To be continued ... |