3

I was the PM for a complex project to upgrade a data communications security protocol used between a large financial organisation and the many other organisations that it shared data with. We had an imperative to complete the upgrade, driven by our regulator, however many of the other companies were not regulated and as such they had no direct pressure to upgrade their ends of the links - apart from the pressure we were putting upon them.

We could plan certain aspects of the work under our own control - for example, making initial contact with the third parties - however we could not control the speed of responses or the proposed timescales from the third parties. This meant that any outline plans we pulled together were fluid at best, and while some of the upgraded links were achieved in what we considered to be appropriate timescales (usually in line with our targets), others took months of negotiation, escalation, and coercion to get agreements to do the upgrades. The physical upgrades were usually quick and easy once we had gained the necessary agreements, but getting to the point where we could do the upgrades was often tortuous.

We managed the work using a pragmatic but very informal Kanban-type of approach, although it was never stated as such. The original plan was to use a waterfall approach as that was what the project sponsor understood, but this was unsuccessful due to the fact that the project didn't fit waterfall. There had been a suggestion that we could use Scrum, however this was quickly discounted as being unworkable given the level of uncertainty within the project, even within a 2 week window.

Apart from adopting a more formal Kanban approach, is there any other approach that might be more relevant for similar projects where there are many unknowns and variables that can't be controlled directly within the project?

3
  • Are you asking in general or for the particular example you posted? In the case of the example I think this could have been managed at the contract level. For example, I've been on both sides of services reaching end-of-life because of replacements releases, like using/providing a version of a web service then a new version was made available. The contract between organizations said that you had X = a reasonable amount of time to migrate to the a new version. After X expired, the old version was decommissioned. If you migrated: good. If not, then things simply stopped working for you. – Bogdan Mar 30 at 15:51
  • @Bogdan - the contracts between the company and its third parties were not explicit as to the requirements to upgrade. Whoever negotiated them (and I have no idea who that was - some were many years old) had not taken account of changing technologies! My question is more about the project management process, although I do agree that an explicit contractual requirement would have made life a lot easier. – Iain9688 Mar 31 at 13:37
  • Just to clarify... we did have the risks of third parties not wanting to "play nice" explicitly spelled out in the risk register. My question is therefore specifically about the project management aspect, and not the wider business constraints that we were asked to work within, caused by inadequate contractual agreements. – Iain9688 Apr 1 at 12:46
2

This is the type of project where it pays to spend some time at the beginning to identify external dependencies. A dependency is a potential risk, so if you can identify the nature of the external dependencies, you can put something about those characteristics in the contract with your partner organizations.

To expand on my comment above, you might for example be a provider of a service or data to other organizations. If you know that the mechanism used to offer the data/service can change, and you don't want to support multiple versions of it, you can impose a period for partners to migrate to the new version (say, for ex, 6 months). After the 6 months pass, you decommission the old version and only provide access to the new one. This basically puts a fire under the other organizations' asses (if organizations had asses :)) to make the changes. You basically make it "their problem" with a contract that they agreed to and signed on (it doesn't need to be a specific period, it can also be to conform to new laws and regulations; a good lawyer can phrase it in such a way that the result is the same). This approach removes the dependencies you have on your partners for making the change.

If instead the other organization is a provider for example, and you need them to provide you with something, then this can also be stipulated in a contract as delivery schedules or delivery dates with penalty clauses, etc. They will then be more inclined to respect the contract instead of taking their time with the work or doing it at their own convenience. The problem with this approach though is that they might take some shortcuts or cut some corners to meet the delivery date, and you might have the dependency met on schedule, but what you get back isn't of the quality you would need it to be.

But even if you identified dependencies in the beginning or they just showed up later, it's important to manage them. The problem with external dependencies is is that they are someone else's work. An external dependency is like a promise. Someone promises to do something for you. But then what do you do? Wait for them to keep their promise? Or remind them to keep their promise? With a friend the former might work, in software development I think the later is a much safer bet.

So you can't wait on dependencies or count on the fact that someone is dealing with them. You need to manage them like any other task that you own. That means to have them visible and continually monitored.

Keeping them visible is easy. You can have them in your Kanban board on a different swimlane, attached or marked on other cards of yours, linked within the tools you are using, etc., doesn't really matter. Even if your board should contain your work, and not something others do, it's still your work to make sure others keep their promise (you can't just mark a date in the calendar and get busy with something else, otherwise it's out of sight, out of mind). So you need to find a way to make the dependencies visible.

Then it's all about communication and being informed about progress. You need to know what's going on so you can plan for the dependency (or around it). The sooner you know something is wrong, the better. This won't be easy - as you noticed and mentioned yourself in the post - if there is no pressure or incentive for others to meet your dependency. If you have a good collaboration with the other organization them you can be kept in the loop, otherwise it's just a matter of pressuring them. Too much pressure, and you can easily end up annoying them to the point of them not responding, or saying things like "it will be done soon", "or that they will try", "they will prioritize it above all other work", etc., which translates to "you will get it when you will get it".

So to answer the question, there isn't really an approach or project management process that might be more relevant beyond what you did, simply because the work isn't in your own courtyard. Others can do whatever they want in their courtyards. If there are many unknowns and variables that can't be directly controlled within the project, all you can do is keep things transparent, visible, and monitored. Handle this work others need to do like it's your work within your project, even if your work in this case is holding someone else's feet to the fire for them to keep their promises. And if you can catch this in a contract by spending some upfront time to think about it, then even better.

2
  • Thanks Bogdan. I think the business owner fully appreciated the points that you make in your email, around contractual dependencies etc. Unfortunately, he inherited the problem, then engaged me as PM to sort it out as a tactical exercise, with the intention of then establishing a better contractual position going forward. I think we did the best that we could in the circumstances, however every day is a schoolday and I hoped that I might have been missing something obvious. It's like the old joke... "You want to go there?... I wouldn't be starting here in that case...!" – Iain9688 Apr 1 at 12:44
  • And I would also like to confirm that we got all of the comments from the third parties that you have predicted! – Iain9688 Apr 1 at 12:48
1

I'm not sure what methodology maps best to this example. It is, as Bogdan notes in his comment, mostly to do with negotiation - getting the other party to the point where they will actually implement the upgrade.

Kanban offers a comfortable way to visualize the progress you have made on the different upgradeable components, but one critical kanban element refers to "work in progress" - the notion that by regulating how much work is allowed to be in progress at a given time, you improve throughput. In this example, wpi is not usually going to be relevant; rather, you're going to be focusing most energy on getting each individual services user to accept the need to upgrade, plan it, and actually implement it.

Likewise, most aspects of agile don't seem directly relevant (although your overall values might play a role in helping companies decide to upgrade, and Agile values might be a positive place to start). Except that, as you note, in many cases you need to apply coercive pressure to get the attention/action you need.

In the end, this feels primarly like a sales issue - selling the upgrade, and not a project management issue, overall?

1
  • "Selling the upgrade" was certainly a part of the solution - explaining the benefits of the increased / enhanced security being part of that, although the kicker was usually explaining that without the upgrade, we would be unable to continue the relationship as we would not be permitted to do so by our regulators. Which was all good if we were providing a service to the third party, but less good if we needed a service that they provided to us, and even more of an issue if there were few alternative service providers! – Iain9688 Mar 31 at 13:43
1

Apart from adopting a more formal Kanban approach, is there any other approach that might be more relevant for similar projects where there are many unknowns and variables that can't be controlled directly within the project?

There are many aspects of Kanban and agile in general that you can benefit from, even when you have many external dependencies.

For example, Kanban encourages you to inspect your workflow and see if it can be optimised, perhaps by the introduction of work in progress limits.

Imagine the following scenario:

The team is blocked with one client upgrade, so they decide to start on another. This happens several times and they end up with several client upgrade projects underway at the same time. This becomes difficult to manage and so as an experiment they decide to limit the number of client upgrade projects they allow to run at the same time. This proves a success as it reduces the cycle time taken for each upgrade project.

Using a Kanban board may also help you to recognise if there are bottlenecks or it may forewarn of future resource conflicts.

1
  • 1
    We did use a very loose form of Kanban board (on-line, as the project team was not co-located... and that's a different issue!) and used it to manage the workflow as well as the reporting to stakeholders. – Iain9688 Mar 31 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.