Delivering projects typically involves a team of experts and potentially a large group of stakeholders. Projects can be delayed in many ways, often unintentionally but also intentionally. In Critical Chain project methodology (see 'Theory of Constraint' by Eliyahu Goldratt), a core technique is to continually search for constraints to fix in order to keep the project flowing with minimal resistance.

Project management best practice recommends that lessons be learnt and applied to future projects or later stages of the same project. Do you follow best practice with regards to lessons learnt? Here is what typically happens:

1. A lessons learnt workshop is conducted at the end of the project (if time allows before the project team is re-assigned to another project). This means that many lessons are forgotten and those that were captured are not leveraged into the current project. 

2. A lessons learnt log is completed to tick the box on the project closure form and once filed the lessons are never looked at again. The effort of capturing the lessons are wasted and the value of the lessons lost.

3. New projects are initiated without any consideration of lessons learnt from previous projects. Lessons are NOT learnt, but mistakes are allowed to be repeated and flaws perpetuated. 

Why are we not learning our lessons? At the start of a project, everyone is focused on getting on with the project and supercharged with optimisms. Once a project is underway, the focus is on meeting milestones, managing scope and dealing with in-flight challenges that reflective lessons learnt workshops are postponed to the end of the project. When the end of the project is finally reached, the incentive to do a lessons learnt workshop is low as any lessons will only benefit future projects. This is a vicious cycle.

In summary, few lessons are captured, even fewer lessons are benefiting the current project, and hardly any lessons are considered by future projects. The consequences are that many organizations stagger from one project failure straight into another failure. This reminds me of Albert Einstein's definition of insanity: "doing the same thing over and over again and expecting different results".

With the benefit of a lot of cumulative hindsight, we would recommend that the Project Management Office (PMO) takes the lead in conducting lessons learnt workshops during and at the end of each project and applying these to future projects. Alternatively, an independent expert such as Caleidoscope Associates can help companies to benefit from lessons learnt by capturing, analyze and leveraging these. 

Here is a great quote that made me think about how people approach the different ways people approach project planning. This quote is from Hugh Lawrie:

"There is almost no such thing as ready. There is only now. And you may as well do it now. Generally speaking, now is as good a time as any."

What is your approach to planning? Do you dive into MS Project or open your favourite project definition template? Or are you more of a avantgard whiteboard brainstorming mind-mapping type?

Whatever your starting point, a some point you need to move from planning to action. For a simple project the plan comes together quickly and is ready for action. What about large or complex projects; do you have to plan the whole project before executing the plant.

Common planning approaches for larger projects are to divide the projects into smaller project phases or sub-projects. This enables you to start the project delivery as early as possible without having to plan out the complete project before starting. No matter how meticulously you plan a project, plans will need to change as reality hits and assumptions are replaced with facts.

IT systems are typically brought in to automate and formalise business processes. Over time, systems are upgraded and new applications are integrated to support new products and organisational changes such as business process outsourcing.

Every time these changes occur, there is an opportunity to re-visit the business processes to check that they are still valid or could be further improved. Most of the technical projects that I encounter ignores the business process improvement opportunity. For those projects that attempts to improve the processes as well as the supporting systems, the process improvement is hampered by functional silos and outdated business policies. Too many business leaders and managers are clinging to the status quo and not looking forwards. Why is that? Usually because the improvement initiative isn't theirs and they have not fully bought into it.

Example: the current policy is to credit check all new customers before providing them with a service. When a new product is launch that carries negligible financial risk the old credit check policy is still applied (and reducing sales). In this example, the business needs to change its policies, processes and IT systems. Any one area is not enough on its own. The alignment from business purpose and strategic goals, through operational policies, to business processes and systems need to be re-assessed whenever a change proposed to any of the above. A change to one area will impact the others as sure as night follows day.

With the right approach, such impact assessments can be done with minimal efforts and time. Done badly, it can consume vast amounts of time and resources, and jeopardise the whole project.

Managing projects is a challenging role because it covers a wide range of activities and no two projects are the same. This means project managers have to master a range of skills and at the same time support others in carrying out their jobs. So who looks after the project managers?
If there is a PMO or programme manager, they may be able to provide guidance, mentoring and support. Some project managers are able to share experience with and learn from  fellow project managers. Others join professional bodies such as the PMI or APM for generic support. Most project managers get along as best as they can by using yesterday's tools and techniques. When did you last study a 'lessons learnt' log?
Over the next few months, we will be sharing tools, techniques, insights and resources to help project managers progress with their career (and projects). Part of this initiative includes sharing the knowledge and experience of seasoned project managers across a range of different industries.
If you have project management experience to share, or some have worked with some outstanding project or programme managers, then please contact us now.

At some point or another, a project or programme manager will be faced with the challenge of taking on an in progress project. The project may or may not have been a success to date, but here are a few suggestions from Intelligo PM on what to do to ensure the project is a success under your leadership:

1. Meet sponsor and executive steering group to understand their expectations of the project and where they think the project is at.

2. Discuss with the project team what has gone well to date and what could be done better going forward.

3. Read the most recent project reports and ask the sponsor or senior project stakeholder attending project update meetings to talk you through the updates to understand the importance of the reported items.

4. Ask the sponsor, project team and the programme office (if there is one) to explain what's coming up or has to be achieved in the next 4 weeks.

5. Identify key deliverables and dependencies along with the status and point of contact for each.

6. Prepare to build your own plan as you may find it difficult to manage and track using someone else's plan. Tell the sponsor and project team that you will need time and their input to construct a fresh plan.

7. Lastly, ask for help. Nobody can expect you to pick up a project where the previous person left. Use the opportunity to build rapport with your new colleagues and understand how you can help them in return.

The US-based project management consulting company Cadence published over 100 short podcast covering a wide range of project management topics.

Although they stopped in January 2013, there are 109 podcasts to help project managers (and general managers!) to sharpen their skills whilst commuting or exercising.

Subscribe through iTunes here:

https://itunes.apple.com/gb/podcast/ask-cadence-project-management/id257164947?mt=2

4. Communication - managing expectations and uncertainties on Agile and Waterfall projects

Waterfall is based on the theory that you decide what you want, document it, design and build, and then test what has been delivered against the documented requirements (see my earlier article on requirement). These steps can then be mapped out and a timescale estimated for completing the project. 

However, as soon as you have captured what stakeholders think they want - at a point in time - new ideas and feedback results in changes to the scope and requirements. Changes also arise from the external market, from new technology, from previously unknown requirements and constraints. This leads to adjustments during the project life cycle and most of the content of project communication becomes centred on dealing with the impacts on these changes in scope, cost and time.

In Agile, is recognized that we don't know upfront what all your requirements will be and that part of the project process is to assist the stakeholders to find out what the real requirements are through iterative refinement. The scope and requirements are expected to change, so the project is designe to manage these iterations (sprints). The communication here becomes focused on deciding which user features to include in each iteration. However, you don't know how many iterations you need or which features will be left out after the scope is drawn for the final iteration. 

So with Waterfall the assumptions are that all requirements are known, all features will be delivered and the project timescale is predictable. With Agile the assumptions are that stakeholders will agree on which features go into each iteration and that stakeholders will commit to the project without knowing the scope, cost and timescale upfront. In this scenario the project communication can quickly be consumed with discussions of relative feature priorities, demand for the project to give assurances of scope and timescale, and dissatisfaction with the limited functionality in a sprint. 

As you can see from the above, the communication needs boil down to managing stakeholder expectations and the inherent uncertainties. My recommendation for managing expectations is to ensure the stakeholders are informed of the journey that they will be part of, what key assumptions are underpinning the project strategy, and what expectations are placed on different stakeholders. This will enable questions and concerns to be addressed early early. It will also highlight areas requiring further clarification or ongoing communication later in the project.

For managing uncertainties (this also applies to risks), the communication process and communication plan should capitalize on uncertainties by demonstrating how the project methodically and deliberately resolves uncertainties. That way, stakeholder trust in the project team and processes is earned from day one, from where the initial expectations are set. 

Communication is more of an art than a science, so cannot easily be prescribed. This means that you should plan for more communication than seems necessary (people can interpret the same communication differently), repeat information (using different modes of communication), and allow for feedback (with short feedback loops). Communication is as much about listening and observing as it is about presenting and publishing. It is also about being, about leading by example (you cannot not communicate!).

Effective communication is the outcome you get (i.e. successful project), not the design of your messages and presentations. The single most powerful tip for effective communication is to be clear on your intent before considering the how, what, where, when and who.

Enjoy this Dilbert cartoon and think of ways the project manager could use communication skills to effect different outcomes. http://youtu.be/52yjQEEdnso

This third article considers project planning and design in projects or programmes using both Agile and Waterfall methods. The project planning stage is an opportunity to identify and examine the interactions between the two methods. We will explore a few examples of such interactions below.

3. Planning and design with Agile and Waterfall

In the first article, we discussed the importance of applying Agile to appropriate projects or project deliverables. In projects combining Agile and Waterfall methods, the article assumes integration between Agile and Waterfall developed software components. It is also assumed that the overall project (or programme) is primarily under Waterfall management and that it has one or more sub-projects managed as Agile projects.

Starting with design, the Solutions Architect is likely to have a longer engagement when a project is using both Waterfall and Agile methods. This is due to the architect continuing the design effort until all the necessary Agile designs are completed.

Until these Agile designs are completed, designers working on Waterfall managed components will be reluctant to commit to work until their parts in the architecture are signed off. Any changes made to the architecture can cause re-work of components managed under Waterfall as Waterfall assumes a stable architecture.

One way to manage the above situation is to schedule the Agile work (that requires integration) early in the project life cycle to underpin the deliverables being managed under Waterfall. If this isn't possible, the Waterfall designs may have to define architecture requirements for the Agile designs to comply with. The latter can be made easier by the Solutions Architect anticipating late arriving Agile designs.

On the plus side, the user stories from the Agile approach should make it easier for the Solutions Architect and System Designers to correctly interpret the business requirements as the stories give a richer context and understanding of business processes than can be understood from functional requirement statements.

There is a risk that the interfaces between Agile and Waterfall developed components will not integrate until the end of the Agile development because of the evolving changes to interfaces. Even minor interface changes can ripple through the architecture design. This can be overcome by defining the interfaces up-front where possible, and by designing flexibility into the common interfaces in anticipation of changes later in the development cycle.

For integration testing, the planning challenge is to ensure all the components and interfaces are deployed in the test environment. If any incomplete components are put through integration testing through stubbing and hand crafted test data, this could compromise the project. Another consideration for combined methods is the need for parallel or multiple test environments to accommodate overlapping setups and test cycles. This will increase the project complexity and resources to manage test environments and code versions.

Release planning also requires consideration as it may not be possible to release Agile sprints until the final sprint has been through integration testing with the Waterfall components. The project manager also needs to ensure robust version control, code merge and test data. For User Acceptance Testing (UAT), the components developed through Agile should be quicker to test as users will be familiar with the software from their involvement in design and development. Be aware that the overall UAT timescale may be determined by testing of the Waterfall components rather than the short Agile UAT.

Throughout the project, it is essential to identify and manage assumptions as Agile and Waterfall approaches will surface different (and sometimes opposite) assumptions. Each Agile iteration may generate additional assumptions so it is important to re-visit all assumptions regularly with the whole project. Similarly, dependencies between Agile and Waterfall components should be clearly shown in the project network and regularly reviewed.

The project manager will face some challenges when asked to forecast the delivery milestones driven by Agile activities. Here, it needs to be decided if timescale takes precedence over cost and scope (I presume quality is not to be compromised). If timescale is the most important factor, then the project may have to time-box the Agile development. Be aware of the temptation to keep the full scope by increasing the sprint size and/or reducing the number of sprints. This is likely to impact the quality and store up problems for later in the project. A reduction in scope for the Agile part of the project could impact the components managed in Waterfall; such scope changes should be done as early as possible to give priority to timescale.

I hope the above examples highlight the necessity for careful planning when combining Agile and Waterfall methods in the same project to get the best from each method. I have found Critical Chain Project Management to be particularly useful when managing projects with many dynamic components and interactions such as those discussed above (see Intelligo PM). In the next article we will look at stakeholder communication in combined Agile and Waterfall projects.

In the first article for this series on Agile in Enterprises with Traditional Waterfall, I gave examples of when and where Agile is appropriate. In this and the remaining lessons I will consider the key differences between Agile and Waterfall as seen from a traditional (waterfall) point of view. This second article focuses on the necessary understanding required to successfully manage the requirements for Agile projects. It is very important to educate stakeholders on what will be different when using Agile and the benefits of using the Agile approach for a particular project.

2. Educating Stakeholders

Whilst the overall aim of the project needs to be clearly understood up front, all the business requirements will not be gathered up front. The Agile approach allows the stakeholders to evolve the requirements based on collective feedback and the value of each requirement to the business.

First, key user stories will be gathered in summary format that can be shuffled like a deck of index cards. Next, when user stories are selected for the first development sprint, it is important to educate stakeholders that prioritisation is based on value to the business. They also need to understand that any outstanding user stories will be placed in a backlog for subsequent development cycles until the business decides there is insufficient value in continuing with more sprints. This means that stakeholders have to be able to justify requirements in terms of value to the business (valued added or lost). 

Then, after each sprint, the stakeholders will see a working version of what has been developed based on their user story input (typically within weeks), and they will have an opportunity to make minor adjustments (e.g. look & feel). Major changes will have to go through the same change process as used for traditional project approaches. New requirements identified during earlier sprints can be added to the backlog for consideration in future sprints.

The user story format ensures each requirement has a context and it can be understood who will use each software feature, for what purpose, and who will benefit. As the user story format also describes the expected outcomes of each feature, this effectively provides a basis for testing and user acceptance. When transposing acceptance criteria to test cases, additional test cases may be required to ensure full test coverage, e.g. negative test cases and non-functional testing.

In terms of project management, the Agile approach requires intense and frequent engagement with a large number of stakeholders. This can be challenging in terms of availability of key personnel and needs to be considered when grouping user stories to be included in the same sprint. Although face-to-face engagement is used a lot in Agile projects, our experience has shown that web conferencing can be a very effective alternative to review meetings. 

Another point to emphasize is that the software that is 'released' after each sprint does not necessarily go into operation immediately. For larger and more complex developments, each sprint provides another component or layer to build up until the overall solution reaches a point where it is deemed sufficient to become operational.

These are some of the main differences to be aware of when managing requirements for Agile projects in a traditional enterprise environment. The traditional approach can benefit from some of the Agile techniques, particularly user stories and prioritization based on business values. At the same time, Agile requires traditional techniques to manage changes and provide project governance. 

In the next article, we will address planning and design.