Data is a differentiator. Companies that can capture what customers buy, like, and use can interrogate that data to provide insights that help them stay ahead of the curve. Big data is the term given to the storage and analysis of workplace data for the purpose of creating meaningful management information.
The data from collaboration and project management tools is a subset of all this data. Real-time project analytics can add huge value to streamlining project management processes and in identifying early warning signs for projects.
Being able to parse a discussion thread from your collaboration tool and single out potential risks and issues could change the role of the project manager in the future. Furthermore, natural language searches will make it easier to include narrative discussions, meeting minutes, and more in the data analysis, saving hours of time when investigating or predicting problems. All of this data could be used to predict the future success (or otherwise) of projects.
There is already work happening in this sphere: The PMO Flashmob here in the UK held a session recently looking at the role of AI in the project office and project management domain. While I didn’t attend, they did publish some interesting Inside PMO report on the topic.
There’s also been a discussion around RPA – robotic processing automation (in other words, using algorithms to process info instead of humans – it’s not ‘real’ robots sitting at a desk next to you doing PMO work). There is a lot of scope for development in this space, freeing up knowledge workers to – you know – actually use their brains for stuff and building relationships to help get projects done.
Data presentation techniques
Allied to the big data revolution is the rise of data presentation techniques, because the trouble with all that data is that it is very difficult to understand. There is a trend toward simple, clean designs for websites and tools with high usability and a very visual impact. The growth of social media sites like Instagram and Pinterest, plus the sudden, recent spike in the number of infographics doing the rounds on sharing sites shows that users are gravitating toward images.
This is relevant to project management collaboration tools because project managers have to adapt the way they communicate to suit the needs of stakeholders. If the needs of stakeholders are evolving to include a requirement for more visuals, then project managers will need to move away from text-based project reports to a more engaging way of sharing status updates.
Visual data presentation is not new to project management—after all, that’s really what a Gantt chart is. Kanban, too, is a visual project management approach and many agile teams work with visual plans. We could well see the visual preference for presenting data manifesting itself in more tools that use images and visual workflows in conjunction with traditional Gantt charts.
This article includes a few points that were made in my PMI book: Collaboration Tools for Project Managers. Given what we’ve been going through and seeing so far this year, it felt appropriate to try to pick out some comments on tech for teams and where that might be taking us – because it seems to me that virtual working is here to stay.
Pin for later reading:
This article is part three of my look into project risk management, and today we are continuing our look into trends and emerging practices, as determined by the PMBOK® Guide – Sixth Edition.
Read part 1 here: An introduction to risk management
Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)
There are three risk-related trends that bear investigation. Last time I looked at non-event risks and today we’re covering project resilience and integrated risk management.
You know about personal resilience, right? I’ve seen a lot written about personal resilience, in particular to do with how we can support ourselves and our families through difficult times. A lot of factors go into personal resilience, from preparedness to mindset.
Projects can be resilient too.
The idea of project resilience relates to unknowable-unknowns – those things we never saw coming and couldn’t have prepared for (have there been any of those lately??). These are called emergent risks: risks you can only identify once they have happened. If your project is resilient, those issues are less problematic because you can deal with them. You can’t stop them, but your project can cope. Or at least, cope better than if you had made no effort to build resilience in the team at all.
Build resilience on your project through:
Resilient projects are more likely to be able to weather the storm and bounce back, because they have space and process to do so. In other words, the better managed your project, the more likely it is that you are going to be able to recover from any curveballs thrown your way.
Integrated risk management
Integrated risk management is simply making sure all the risks from the project are integrated into a bigger picture. For example, your project could be part of a programme. On the last programme I ran, we consolidated risk from all the projects so we could assess the overall health of the programme, and that overall position was reported at the programme board monthly.
Integrated risk management processes mean that risk is owned and managed by the right people in the organisation, at the right level. So as a programme manager, I wasn’t reporting up every single risk those projects had, but the important ones. There is a level of professional judgement applied to back up the risk assessment process, so that the significant risks are escalated to the level they need to be known at.
Beyond projects and programmes, integrated risk management also looks at how project-level risk relates to the portfolio as a whole. This information is useful because it helps executives get a clear picture about the level of risk the business is taking with regards to delivering change. If too much change is going on, they might consider that too risky, and slow down or postpone some projects until other initiatives have completed.
Enterprise risk is the next level. You may have a corporate risk manager: their job is to aggregate risk from all over the business. They’ll be looking for input from each department but also projects and programmes, and the entire portfolio, and considering how that works with and affects operational risk too.
Basically, integrated risk management is the overall corporate governance structures and framework for managing enterprise risk. As a project manager, you need to know how you fit into that, but the whole thing isn’t your responsibility. You should carry on managing risk as you do, making sure the people who need to know about significant project risks, know.
Next time: I’ll look at tailoring risk management for your environment, because a one-size-fits-all approach doesn’t work.
Pin for later reading:
This is the end of my deep dive into the PMBOK Guide®-- Sixth Edition, and what it covers about Project Schedule Management. I’ve looked in detail at the major changes between the Fifth Edition and the current version.
One of the biggest changes in the Sixth Edition is the inclusion of information on trends and emerging practices, tailoring and Agile. This is long overdue and it’s helpful to have some specific guidance around how we can adapt the sometimes dizzying amount of information in the PMBOK® Guide to our own organisations.
To recap, here is the rest of the Project Schedule Management deep dive series:
OK? Let’s take a look at what you need to know about adapting this process for your environment.
Trends and Emerging Practices
Scheduling techniques have pretty much stayed the same for many years, but there are some new thought processes at work. We have to be able to manage in a competitive environment where everything seems to be needed much more quickly. There’s a business advantage to being able to compress schedules and deliver things in a shorter timeframe, so the emerging practices covered in the PMBOK® Guide relate to those.
First we have iterative scheduling with a backlog. This is a common way of managing work in an Agile environment and supports rolling wave planning. In other words, you have a big bucket of requirements (user stories) that are prioritised as you come to the end of a time box, for delivery in the next time box. This works really well when you can or need to be flexible about what features get released when.
The major benefit is that the customer gets to see real progress on an iterative basis. This is great for building loyalty, delivering benefits more quickly and ensuring user adoption over time.
However, when there are lots of dependencies between tasks or requirements, it can become difficult to manage.
On-demand scheduling is based on the theory of constraints. It limits the work in progress for a team so that you can balance demand against what the team is capable of doing. As someone who is not a fan of multitasking (although I do it every day), limiting WIP is a great idea.
Kanban is where you will see this approach in use most commonly. In practice it works because instead of building a schedule based on requirements, you plan around the team’s availability and they take work from the queue to work on it immediately.
This is a good approach in environments where you have people doing a mixture of BAU and project work, and their project work does not have hard deadlines. I have no project experience of on-demand scheduling, aside from using something similar for my own To Do lists, so share your experiences in the comments below – I’d love to hear more.
The PMBOK® Guide talks about the need to tailor the approach to scheduling because every project is different. For your project, think about:
The life cycle: what life cycle are you using for your project and is it the best approach for getting to a detailed schedule?
Resource availability: You might have to switch up how you manage the schedule because of difficulties securing the resources you need.
The project itself: Big, complex projects need a different approach to scheduling to a small, easy project. There might be constraints within the project environment that lead you down one scheduling path compared to another, for example being required to use earned value as a stipulation of a particular contract, or using a particular scheduling software tool because that is what the client uses. That leads us to:
Tech support: What tools are available to you? If you don’t have access to modelling tools, for example, it’s not appropriate to build your schedule on the basis that you can use them. If you don’t have virtual Kanban boards and yet your team is virtual, then perhaps a scheduling approach that relies on specific software isn’t the best way to go.
Considerations for Agile
Adaptive project methods are those that use short delivery cycles. You do the work, review the outputs and make changes as necessary before the next delivery cycle kicks off. We’re seeing more and more projects use agile approaches like this because they work.
However, in my experience, and that of the many project managers I mentor, a lot of companies have project teams doing agile and project teams who don’t use agile. Sometimes we use Agile and non-Agile techniques on the same project (for different aspects of the same project). There’s a recognition now that this is OK. If it works and you get results, then it’s OK.
The PMBOK® Guide talks about hybrid approaches and being able to combine scheduling techniques from different approaches to get where you need to get. As a project manager, you have to make or support decisions around the tools and approaches you are going to use, and it helps to have some experience of these. If you find yourself suddenly managing an Agile project with no prior experience, you’ll be fine, but get familiar with the approaches as quickly as you can!
Pin for later reading:
In my new book, Collaboration Tools for Project Managers, I explore the opportunities for project teams working with new technology.
Here are two emerging themes in both project management and in social and collaborative technologies that are worth knowing about.
1. Digital PMOs and the Role of the Digital Leader
Disruptive technologies such as big data are hitting businesses across all functional areas, not just project management. Companies have to come up with practical ways to incorporate this massive amount of change and to sift through the trends that are worth adopting while ditching those that are not relevant at this time.
This is starting to come to the fore in the form of the chief digital officer or other digital leadership position at the very top of businesses. We are also seeing digital PMOs—divisions supporting the project structure in the way a traditional PMO would, but with a leaning toward paperless, integrated, and online ways of working, along with the culture changes that brings.
2. The Culture of Collaboration
It’s not all about the tech. Part of the challenge facing the digital leader, be that a project manager or a PMO director, will be managing flatter teams, both across business teams and within projects.
Employees will create their own internal networks outside of the traditional hierarchy, which potentially makes many of the formal line management structures redundant and forces the organization to become flatter. The digital divide—those employees who are familiar with digital working practices and those who are not—is a further team-related problem that digital leaders have to face up to and proactively manage.
"If virtual teams are to be successful, and if collaboration tools are to be fully embedded in the working practices of the team, then it’s important for businesses to invest in collaboration offline as well."
Successful collaboration and teamwork comes from a culture that supports those ways of working. If virtual teams are to be successful, and if collaboration tools are to be fully embedded in the working practices of the team, then it’s important for businesses to invest in collaboration offline as well.
We’ll see greater investment in building corporate culture, fostering employee engagement, and creating the environment to deliver successful change. All of this underpins the use of any technology and supports the business objective of getting the right people to do the right things the first time, which cuts down on overall project costs.
3. Knowledge Sharing
A collaborative culture also supports the urgent need for knowledge sharing in a global economy that is facing significant talent gaps. As the Baby Boomer generation leaves the workplace, taking with them an incredible amount of organizational knowledge, companies need to find alternative ways to capture and maintain their knowledge assets. Technology (like wikis) has a part to play, as well as collaborative work environments where knowledge is freely shared.
What trends have you noticed?
If you're interested in finding out more about how project teams can benefit from using collaboration tools, you can get a copy of the book from the PMI Marketplace here.