The Money Files

I don’t know about your projects, but the role of data privacy and information governance has certainly expanded since I started managing projects.

Data privacy has become a critical concern for organisations globally, and you only have to look at high-profile cases in the media about ransomware attacks, data leaks and breaches to realise that we’re all only one potential hack away from a major problem. Is that on your risk register? It could be.

Projects use or create a lot of sensitive data, depending on what industry you are in. Even if you aren’t dealing with medical records, your project probably includes some confidential company information for you or your clients. Even operational data could be sensitive if a competitor got it.

Therefore, project management processes have to take into account data privacy standards. Meeting those are the basics. You have to maintain trust in your organisation and avoid exposing the business to significant legal and financial consequences. Non-compliance can result in fines and reputational damage, and there are plenty of cases in the UK, for example, where GDPR breaches have been heavily fined.

In this article, we will discuss the key data privacy regulations that impact project management, how to assess your project management tools for compliance, and steps you can take to ensure your team handles project data securely.

Data privacy regulations

I know that readers come from all around the world, and privacy laws differ, so I’m not going to try to list all the relevant global legislation. Suffice to say that in the UK where I am based, GDPR is a key regulation. Where you are will no doubt have similar regulations on how personal data is collected, processed, and stored.

The laws that I am aware of generally all have similar aims: to ensure data is collected for the right reasons, stored securely and disposed of appropriately, and that data subjects know what is being done with their personal information.

Key principles of data privacy

Projects should take into account how data privacy is going to affect the work of the project and deliverables. Generally (although I’m not a legal expert in your country’s regulations, so take advice from your information governance team), what you are looking for are the following.

Data minimisation

Collect only the data necessary for the project’s purpose. Don’t collect extra things because they would be nice to have or would help a future project. Work out what data is required for the purpose of this project, and that’s all you can have.

Purpose limitation

This principle says that you have to ensure that data is used only for the purpose for which it was collected. In other words, if your project is collecting data for the purpose of processing a customer order, you can’t then use it for something else.

Consent management

People need to know what they are consenting to and what you are going to do with their data. this is all about transparency. If your project is collecting data from people that you didn’t have before, obtain explicit consent for that. Mostly this will be covered off by any privacy notice you have on the site, or in your terms and conditions – so you must make sure your project links in with any existing consent management systems (or builds a new one if needed)

Data security

Not surprising – if you need to build measures to protect data from unauthorised access, breaches, and leaks, do that, or tap into what already exists. This goes for user access too, so make sure only the right people in your company have access to data.

Transparency and accountability

Keep clear records of data handling practices and be transparent with customers about how their data is used. You may find this is already covered in existing terms and conditions or privacy notices, but always take advice from your legal or information governance team, or data protection officer to make sure your project isn’t introducing anything that would diminish existing processes or require new ones.

I’ve been managing a programme for a while now, and it’s quite different from managing projects, or the very large projects that we call programmes that are really not programmes!

Programmes need their own budget as well as the budget of the projects, and here are the things I think should be included in that.

1. Costs of running the programme

It seems silly to point it out explicitly, but there are costs incurred from running a programme with a programme management structure.

For example, my time as programme manager needs to be costed and included along with any support resource from the programme office. Even though we are not full-time, the programme wouldn’t run without us so our costs have to go somewhere.

Ideally, there would also be a programme-level risk budget for handling unforeseen issues.

You may also find that on your programme there are other costs associated with running the programme, such as office space, software licences for third parties to access your programme management software (which is likely to be the same project management software everyone else uses, so hopefully not too large of an overhead there).

2. Assurance costs

Are you planning on having internal (or external) audits and reviews as part of the programme? If so, those costs should be picked up by the programme budget.

Internal reviews, in my experience, don’t cost anything except time, but if you are bringing in consultants or external auditors, there is definitely a cost associated with that (as well as time). Certification or compliance programmes may have extra costs here too, for example, if you have to comply to certain standards, going through the accreditation process is both time-consuming and normally costs something. There’s also often an annual cost to main the accreditation so factor that in too if your programme is multi-year.

Plan all those costs into the programme budget at the frequency and estimate required.

3. Benefits realisation costs

Benefits might be realised at project level, but you’ll likely have some programme benefits to track as well. And the cost of delivering and tracking those should be included somewhere – in your programme budget.

For example, you may need to programme software to create new reports. You may need a new role, and someone hired to go into that role. Some benefits might include making staff redundant due to organisational restructure, and there are costs associated with that activity too.

Plan all of those in at programme level. You may find that it’s useful to take the project-level benefits realisation costs into the programme budget as well so you can track benefits all in one place, but that’s up to you.

Project costs

Of course, there are costs to running the projects too, and in your overall programme budget, you’ll want visibility of those for forecasting and tracking. But these are the ‘obvious’ costs so it’s likely you already have them.

The project costs would normally include the large infrastructure type items that are necessary for the programme to move forward. The first project would normally take the hit for any large infrastructure-type investment, but that makes the business case for that project rather wobbly. You might decide that large capital costs are picked up by the programme as an overhead instead, and then each project goes forward on its own merit without having to fund the infrastructure required to make it and future projects work.

Talk to your financial analyst or project accountant for how best to apportion the costs across the programme and projects so it’s transparent and reasonable.

A couple of times people have said to me that sharing the project budget with their team members is Not A Good Idea. I don’t know why that is the case – they are stakeholders too. I think it is essential to be transparent about the budget, how it was created and how you, as a team, are doing with spending it. It helps the project team come together with a common objective, and it helps build trust in the way in which things are being done.

In his book, Employees First, Customers Second, Vineet Nayar talks about 5 ways that transparency helps build trust among the stakeholder community.

1. Understanding the bigger picture

“Transparency ensures that every stakeholder knows the company’s vision and understands exactly how his or her contribution assists the organisation in achieving its goals,” Nayar writes. In project terms, it is difficult for a project team member to contribute effectively without knowing what the bigger picture is. In budget terms, if team members don’t know how things are going overall and how much their elements are costing, they cannot help work more efficiently to get the job done.

2. Generating personal commitment

Nayar says that transparency ensures that “every stakeholder has a deep, personal commitment to the aims of the organisation.” I don’t believe this is true. Transparency may contribute to building this, but it is not the only way you get people to feel as if they are personally committed to a project.

3. Transparency is a given for Gen Y

The younger project team members will expect full transparency, and without it they will be suspicious and untrusting. “They post their life stories in public domains,” says Nayar. “They expect nothing less in their workplaces.”

Again, there is more to this than I think he brings out in the book. Transparency about the budget and all other elements of the project will help generate trust in team members of all ages. Generation Y team members may have a different expectation of what is appropriate to share, but sharing (or not sharing) will have an equal impact on the trust levels across the entire team.

4. Corporate transparency promotes customer transparency

Nayar says that in a knowledge economy, it is important for customers to share their ideas with companies. This is the way that we find out what products they want, how their lives are evolving and what would make their lives easier. They may also have ideas about solving problems with our products or corporate challenges that we are facing. “Why would a customer be transparent with a potential partner like us if that company does not trust its employees enough to be transparent with them?” Nayar asks.

This is a fair point. While I would not advocate sharing the project budget with customers (unless your work is in the public sector and this is therefore expected), it is a good idea to share the budget predictions with your suppliers and partners. Why not? It will help them pitch their services at a price that creates a win-win situation for you both. In one case I heard about recently, a supplier opted not to pitch for work when they heard the budget figure that the company in question had available. It saved both the company and the supplier a lot of time in the tendering process. Share your budget figures with people outside the immediate project team. Or at least consider reasons why you shouldn’t, and then critically assess those reasons to see if they still stand up.

5. Transparency helps contractors

Finally, you need to consider the work of contractors. “The only way these outsiders can get up to speed quickly and be as effective as possible is through sharing of information and complete transparency about the strengths and weaknesses, the issues and concerns, of the assignment,” Nayar writes. “The more transparent the process, the more trust that the outsiders felt in the organisation, the more we could reduce the amount of learning time, which would give us an advantage over our competitors.”

If you share project information with contractors, it helps them feel more comfortable in their role. It will also help other team members, who have to deal with these contractors, feel as if the contractors are offering a valuable service and are actually making a contribution. If the contractors operate without full visibility, other team members may well feel as if they cannot trust them to make the right decisions because they do not have all the relevant information.

How transparent are you with your project budget? Do you share this information with stakeholders as willingly as you share other project information? If not, why not?

This month, the discussion topic here at Gantthead is stakeholders. Project stakeholders need documents – but how do you know how much documentation is enough? Unfortunately, the answer is always, “It depends.”

The amount of documentation stakeholders need to feel comfortable depends on:

• The project scope
• The project size
• The project’s requirements and how complex they are
• Any legal requirements
• Any financial requirements
• Your company’s documentation standards (although you could flout these if you have good reason)

According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document:

Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change.

Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan.

Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes.

Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.

You may find that it is easier to have two versions of the project budget: one definitive, signed off, formal version of the budget that never changes and acts as a reference point (your project budget baseline) and another as a living document that you update for quarterly forecasts and use to record actual spend. Personally I spend much more time on my living document than I do going back to the original, but I know that at the end of the project I will be expected to justify any changes to budget in the post-implementation review, so it’s important to still have those figures unchanged, with details about the project assumptions that helped shape them as no doubt by the end of the project I will have forgotten why the budget was set up that way.

Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again?

Last week I shared with you some questions and answers from my recent webinar on managing money on projects.  I wasn’t able to answer all the questions after the presentation, and those questions I didn’t get a chance to answer in person I am answering here.

Here’s another batch of Q&A.

Can you give a definition of "Consultancy"?  Is that research/consulting on tasks OR the hiring of outside resources to assist with the project tasks?

I think it’s both.  If you don’t have the skills amongst the permanent staff in your organization, you need to hire those skills in.  The people hired could be doing specialist tasks like research or technical consulting, or they could be an extra pair of hands to help you get the project done, like an extra project manager on a large program.  Either way, these are additional, external resources and that’s what I mean by ‘consultancy’.  Essentially, it is paying for people who are not permanent staff.

Do you ever find that being transparent with $$$ leads the funding away from your project and onto another "priority" thereby interjecting project risk?  Seems like the norm is to cloak the budget until successful completion and then release at completion with the rest of the resources.

I think this is very dependant on the culture of your organization.  Fortunately I have not worked anywhere where I have seen this happen, although I wouldn’t be surprised to learn it did go on in some organizations.  It is all to do with what the company thinks are its strategic priorities and unfortunately your project might not be one of them.  A strong PMO can help here, as well as a mature project management culture where people understand the value of not chopping and changing their minds about projects every five minutes.  Projects cost what they cost, and if the investment is worth it and you haven’t padded out the budget unnecessarily, you shouldn’t have to worry about sharing the figures.

If your project is no longer a strategic priority it seems sensible to me to divert the funds on to something else that will deliver great value for the organization.  If you are worried that your management team doesn’t have the foresight to do this which leads you to hiding your budget until the project is over, they all need to go on Sponsor training!

Do you consider utilities, rent, etc to be a project management cost or deliverable cost?

Utilities, rent and so on are project management costs.  Let’s recap the difference:

Project management costs are the costs of doing the business of project management e.g. paying for your team members, training including the costs of a trainer, room hire, refreshments, delegate transport and accommodation, hosting large meetings off-site and hiring equipment.

Project deliverable costs are expenditure directly related to what the project is going to deliver e.g. software, hardware, purchasing equipment, licensing and things like buying software and funding anything that will change as a result of your work like new stationery or user guides or paying for documents to be translated.  

Might training be considered a deliverable cost associated with quality assurance? What about testing resources?

Yes, I suppose they could be.  The purpose for me of categorizing costs in this way is simply to provide a starting point for preparing a comprehensive budget.  People often think about what they need to buy to deliver the deliverables – a new server, new office equipment, software licences etc – but they forget about the costs required to make it all happen.  These are what I call project management costs and are the overhead of running a project.  In real life it doesn’t matter at all if you categorise training as a deliverable cost or a project management cost – the important thing is that you have considered it and included the cost in your budget.

You can see the whole presentation online here, via a recording of the webinar.  I’ll have some more Q&A for you soon!