The Money Files

Do you use a wiki at work? Do you have a LinkedIn profile for connecting with work colleagues? If so, you’re using social media professionally. In this post, I wanted to get back to basics and explain how social media works. Social media tools work because everyone (with a few tiny exceptions) follows these seven guiding principles that form the basis for the structure of the social media space:

• Community
• Collaboration
• Communication
• Constraints
• Connectivity
• Channels
• Content

Let me elaborate.

Community

When groups of people come together with a common objective, you end up with a sense of community, almost by default, like this community at Gantthead. You get a sense of community because people can interact with each other. The web enables us to do that – through forums, star ratings, collecting badges, leaving comments etc – more than any other form of media.

The internet allows groups of like-minded people to come together, and project managers can tap into this.  After all, your project team is like-minded, with a common objective:  to deliver your project.

Collaboration

Collaboration is the foundation which all social media tools are built on:  the fact that people want to work together. If people don’t share, there isn’t much to see online. Many websites (again, like this one) draw on the collective knowledge of experts who are sharing their skills.

And it no longer matters where you are based. Technology makes it possible to work across time zones, languages (hurrah for Bablefish!), and with people you have never met. Suddenly, working with project team members in other countries seems possible.

Communication

Communication and collaboration go hand in hand. If collaboration is the multi-faceted linking between groups of people with common interests, then communication is a more of a one-way version of the same thing.

Your team may be very collaborative, but there will always be times when you need to tell them something, for example sharing the project board report or to update them on a change of company policy.

Communication also needs to be honest and transparent. You’d expect that with any form of communication, but one of the underlying principles of the web is that you don’t share misinformation deliberately.

Constraints

As much as many managers would like to believe it, online is not a place where it’s a free for all. Just as in the office, online there are expectations for behaviour, such as not TYPING IN CAPITALS (can you hear me?).  Don’t say things to people online that you would not feel comfortable saying to their face: instant messaging for work might be good but that style of communication could slip into unprofessionalism easily if you are not constantly aware of your communication style.

Constraints and good practice around how to interact with other people online have been consolidated into what is called netiquette – manners for internet users.

Connectivity

Duh. Social media tools work best when you are connected to others online! Lucky for us we now have smart phones.

Channels

A channel is just a word to describe the way information gets delivered.  As a project manager, you need to decide what channels – technologies, software tools, platforms, hardware – you are going to use.  Different channels work well for different types of content, so if you want to share photos, you’ll choose a different channel to if you want to get people working on the same document at the same time.

Content

If you read websites about social media marketing or personal branding, you’ll hear experts go on and on about content. It’s what you share online. While some of your project information may not be the most interesting in the world, it is still useful to your audience. But if your project team stops finding the project blog or the wiki useful, then they will stop visiting the site.

In this instalment of Ask the Experts I talk to Jon Swain, President of Virginia Beach-based firm Ten Six Consulting. Ten Six specialises in enterprise project management tool deployment, so I talked to Jon about what these products can do and how they can help project managers work more effectively.

Jon, when I think of enterprise project management tools, I think of scheduling. What else can they do?

There are many features that take EPM tools beyond just scheduling. At a high level, EPM tools offer a centralized repository with all of an organization's project information in one place.This is coupled with a role-based security structure that allows an individual access to only what their role needs. Because you can centrally control the environment, you can enforce process disciplines. For example, take baselines. Baseline discipline is sometimes difficult to achieve with standalone tools as the project can re-baselined at any time without a formal process to control that. In EPM tools, you can better control the schedule from being informally baselined.

With everything in one place, senior management can see up-to-date project performance data across the whole organization allowing them to better manage their project portfolios. They can proactively choose which projects to select, prioritize projects particularly with competing or scarce resources, understand the interactions between projects and tie all of these decisions directly back to the company's strategy and goals.

So portfolio management is a big chunk of it. How do they fit into the rest of the systems in use?

It's not uncommon for EPM tools to be integrated with other enterprise systems including HR and accounting. Two very simple examples of these include allowing the synchronizing of resources from an HR system and the collecting of actuals costs from an accounting system. A project manager can not only plan and profile their budget, but accurately track project spending by collecting actual costs from these systems. This gives you a complete picture of your project finances. This kind of integration and information sharing at the enterprise level are benefits that stand-alone implementations of project management tools can’t easily match.

In addition, collaboration is available with many of the EPM tools today emphasizing the importance of collaborating and communicating to improve productivity and drive project success. These capabilities can enable the better management and sharing of project artifacts.

It would be remiss of me not to mention the tool vendors embracing web-based technologies. Having all this functionality in a tool suite that is now 100% web-based, makes it far easier from an IT perspective to deploy and manage large numbers of users.

That sounds great, but expensive. How do they pay back?

Many organizations that are not using EPM tools often have no way of measuring organizational project performance with empirical data, resulting in subjective assessments that can be misleading.

By way of example, a successful deployment across a 'green field' IT organization of say, a thousand staff, can yield millions of dollars in savings. These savings can come from improved project selection, removal of duplicate effort, better utilization of resources on the right projects, improved project delivery and reduction of project risk, to name just a few. These are fantastic benefits that any company could and should enjoy.

Also, learning from past project performance increases the likelihood of better estimating on future work. Building on past project successes helps create best practice templates that can be reused time and again. It's a cycle that naturally drives continuous project management improvement over time.

The customers in which Ten Six have successfully implemented EPM tools are reaping huge benefits and often have an improved organizational culture with a motivated staff that is focused and all pulling in the same direction.

I imagine you can get a lot of reports out of these systems. How does good reporting help a project manager make their project more successful?

Reporting plays a big part in supporting the project manager. EPM tools provide real-time information on the status of their project, which is presented in the format and style that they need to make decisions. These reporting capabilities can be extended using third party reporting tools, allowing complete customization of report formats and the ability to include information from other systems.

Getting the right data out of these tools is no longer the only priority; great graphical presentation in specific formats for different roles including senior management has become just as important. Web-based dashboards also play a large role in supporting both project managers and senior management in their decision making process.

I'm convinced. Is the next step to pick a tool?

There are three elements that are often talked about when implementing EPM: first tools, second processes and third people. Most organizations that are implementing EPM tools for the first time focus on these three things in that order.

In our experience, they should reverse the order to get better results faster. In other words, implementing the tool is typically the least of your challenges. Cultural issues, change management and user adoption are the challenges that need to be overcome to ensure a successful EPM tool implementation. So, if the priority were people, process and then tools, more emphasis, money and effort would be spent dealing with these “soft” issues that can slow down or even stall an EPM implementation, ironically making the implementation more expensive!

Thanks, Jon!

Project budgeting is all about using your best estimates to work out how much the project is going to cost. But it never costs what you think. Something always gets in the way. There will be an issue, or a schedule overrun, or an addition to scope that makes the original budget estimate different from what the final cost is.

So, you know the final cost of the project at the end, right? When everything is accounted for and all the project-related costs are spent.

Michael Cavanagh, author of Second Order Project Management (2012, Gower), doesn’t think so.

“Although it has been said often that the only time you know the cost and duration of a project is when it has been delivered, in truth, you don’t,” he writes. “Post-delivery costs including fault correction, maintenance, support and disposal are all subject to the vagaries of implementation in the real world and should be addressed and included in the estimation process.”

Cavanagh is talking about putting together a comprehensive contract with a third party supplier, but the same holds true even if you are building your project deliverables in house. However, I don’t completely agree.

I have to say that I hadn’t considered the cost of fault correction as a project cost. For me, the delivery of the project does not happen at the point that the deliverable is launched. There is a handover to support period, and in that time you would warrant that the products provided are fit for purpose. If the deliverables have been signed off, but a bug is identified six months later, then this is not a project cost. It’s a cost related to potentially a change in the way the product is used, and is part of the product lifecycle costs but not the project lifecycle costs.

I do believe that maintenance and support are project costs, at least for Year 1. Typically – and this will depend on your company’s accounting rules – maintenance and support for the first year are included in the project budget. Maintenance and support for Year 2 onwards are business as usual costs. A lot of this is to do with whether you can capitalise maintenance and support fees, and whether your project has an opex budget or not. Check with your finance team if you are unsure on whether you can include maintenance and support in your project budget, and for how long.

Disposal costs are also part of the product lifecycle in my opinion. I would never include in a project budget the costs for disposing of an asset my project brings into service. How would I know what it would cost to dispose of in ten years time? Or longer, depending on what it is?

However, there may be some products that are decommissioned directly as a result of your project. For example, as part of a project to replace a piece of software with something new, the old software becomes defunct. The cost of decommissioning this is a project cost.

The full product lifecycle costs including disposal, servicing and maintenance should be included in the project business case. That document is all about making good business decisions so they decision makers should know exactly what they are signing up to, both now and in the future in terms of recurring costs like maintenance. But what goes into the business case does not automatically go into your project budget.

When you budget, do you take into consideration the life-long costs of the project, or just the implementation and set up costs? Do you agree with Cavanagh?

As part of your project status reporting you probably include metrics. You might even have a project dashboard that calculates the metrics from an enterprise PM tool and displays them for you. Project metrics are things like resources consumed and estimate to complete. Some metrics mean more to stakeholders than others. Personally, I am not a fan of percent complete for tasks, for example.

As least one of your project metrics should relate to your budget – assuming you have the responsibility for tracking how much the project is spending. There are a number of different ways to track the budget, for example:

• Earned value management metrics
• Variance to forecast
• Percent of total budget spent
• Budgeted estimate at completion

Again, project stakeholders will respond better to some measures than others. It depends who they are, what they want, what they need to do their jobs and what their previous experience is. A project sponsor with a finance background is likely to want a far greater degree of visibility of your budget than someone whose main focus is quality. Your job is to find out what they want and provide it.

It really doesn’t matter what the metric is that you use, provided it fulfils two criteria:

1.      It must make sense to the people who are using it

2.      It must have clear boundaries defined so that you all know what ‘red’ means.

There is no point in having Red, Amber, Green (RAG) or any other categorisation method (click here for a Gantthead discussion on how to categorise projects) if no one knows what the different categories mean.

Set thresholds. Define what the tolerance levels are for each metric and publish them. Then stick to them. Your budget RAG status could look like this:

Green: within +/-1% of budget

Amber: within +/- 5% of budget

Red: over +/-6% of budget

Choose figures that make sense to you: 1% of a £5m is not very much in the grand scheme of things so you could probably agree different tolerances with your project sponsor. As long as you are clear about what ‘Red’ means, everyone will be operating from the same information and your metrics will be meaningful.

How do you define Red?

In this video, I look at the hidden cost of project changes.