The Project Manager has to avoid "scope creep" ?

If we just do what we are told, without thinking, then we can remain within scope. However, what if we think too much? What if we really want to identify risks? What if we really want to help? Could we try too hard?

I started writing a fictitious project brief, to showcase what I can do. I wanted something which was business focused, but where I could high-light my technology skills. Here’s why; in many cases the “Project Board” have decided what they want. Our role might be to add the detail, and make sure that the various stakeholders are in agreement, and everyone knows their roles & responsibilities. We need to drive the project, and coordinate activities, but we need to remain "in scope" ?

We all know that people and businesses must change, but even getting the project brief right, and keeping it constrained, can be a challenge.

Here’s what I started with, and I am sure you can see how easy it would be to let this run away from us. I guess, it reminds us why we need to exercise “change control”, over ourselves?

This first part is the "Background" which has come from the (fictitious) Business or Programme briefing. The "Project Definition" is further down. You will see there are many things you will want to add. But, that's the problem? When does the project manager become guilty of "scope creep", because he/she was trying to identify every possible risk?

As I started writing this, I realized that my "project", had to become itself a "Programme". Note. I have done this before in Citibank/Citigroup. At that time it was a series of stand-alone projects, which happened for ad-hoc reasons. The following has nothing at all to do with Citibank. I mention this to show I have done this before.

Please read on;

Background

This Application Consolidation & Ongoing Support project is part of the XYZ Financial Company Re-Structuring Programme. The programme is outlined below.

The XYZ Financial Company is a small European Bank. The firm is headquartered in Germany, and has offices in 22 countries in Europe. There are 3,000 staff, spread across 33 offices, of various size.

They have decided to re-structure their Business. There are several factors influencing this, summarised as follows;

• Competition from North American Banks. They have largely driven down their operational costs, and are targeting new revenue streams. They will be targeting new opportunities which deliver higher margins.
• Geo-Political issues across Europe mean that the XYZ Financial Company needs to be more flexible in terms of “in-country” presence. This includes the physical offices, and how staff work, i.e. “face to face”, “video”, “chat”, "social media" etc.
• Changed transaction models, such as Bitcoin, and CrowdFunding have affected how people and Businesses move money, or source capital. The old ways of banking and moving money are changing quickly.
• HR. We need to understand how our staff support the Business, in terms of location, geographies, and teaming. If the business goes through a major re-structuring we need to identify which staff will want to continue in role/location, and which will not.
• Incompatible Office Types. There are a mixture of different office platforms, which accommodate between; four staff and three hundred staff. This makes the Buildings difficult to manage.
• Computing, the Internet & Telecommunications. The technology boundaries between these have gone.
• The firm has outsourced the day to day support of basic IT. This includes; database, network, and client device support.
• The central computing systems are based in company owned datacentres in Germany, France and the UK.
• The Software Applications that support the firm have evolved over many years. They are linked between sites. Some supported by vendors, others by niche software firms, and many specialist support companies.

There are Office Support Contracts with over 2,500 different companies. This includes; Building Contracts, Utilities, IT Support, Catering, Insurance, Cleaning etc.

The firm plans to open a series of satellite offices in North America, and partner with one or more North American banks. The objectives of this are to gain Financial Licenses to operate in North America and become the preferred route into Europe for those North American banks.

It is estimated that it will take five years to manage any office transition strategy. i.e. to allow time to sell any offices, and ensure that the XYZ company is not paying for facilities that are no longer in use, while they transition to any new facilities.

The longer-term plans are to focus their offices in three geographies; Germany, the UK, and USA.

The AIM is to build a Financial Business which targets attractive opportunities, using staff and resources, deployed “in-country”, as required, rather than the current model which tries to attract customers to come to them.

Project Definition (this is focused on the software applications)

Note. As I started to write this "showcase project definition", I realized this would have to become a Programme, due to the complexity, and number of projects involved. However, the same issues would be valid for a much smaller organization, so I am leaving this as it is. i.e. it's easier to downscale, than upscale.

Application Consolidation & Ongoing Support. This project will identify the Applications which support the firms processes and procedures, and how they will be supported ongoing.

It will deliver the following, and be displayed using an “Application Discovery and Mapping” tool.

• Identify an “Application Discovery and Mapping” tool. This will identify and produce a “map” of all programs, libraries, databases, services, and all components necessary to identify all elements needed to support the existing business software applications.

This will then allow;

• A list of all applications. An application may include one autonomous program, or more likely need multiple programs, integrated together to deliver an application.
•  In terms of the Listing of Applications, identify any programs which can operate independently, or as a module. e.g. if the bank has (for instance) 2,000 programs there may be some programs which can operate independently, or as part of a module that includes a small number other programs, which together deliver an application.

Separately to the above, but included within a report;

• Categorise all applications. Are the applications scheduled to be “EoL”, if so when? What Business Units does each application support?
• Identify the physical locations of all applications, and the physical locations of any dependencies. e.g. consider web-servers, application servers, databases, back-up, and DR.
• List how each program is supported, and then how any application is supported. This should include operating systems, databases, and third-party plug-ins.
• List any customer or client-side requirements. i.e. if any changes are made to any corporate applications, what (if any) changes need to be made to customer, or client-side systems, or devices.
• Identify any existing performance, security, or other operational issues that are effecting any existing programs, or applications.

Summary from me; if you have a technical background, you will see many deficiencies. As a project manager, it's tough not to drill down, from a work package type level to a team manager type role, where you want to get into the detail.

Conclusion; I feel, we need to keep the work package, limited to;

• If this is the input, and we want this output, then we pass that to the team manager.
• We then use our technical knowledge (if we have it) to equip us better to review the team leaders plans.

Remember; Prince2 says we don't need to be technically capable, in any field. In one way that could be better, because we would be less inclined to get into the detail. On the other hand, I prefer being "technically capable", as it helps me know what's going on.