The next focus. While many people are talking about legal ownership of your data, I am going to focus a little bit differently by takin

The next focus. While many people are talking about legal ownership of your data, I am going to focus a little bit differently by taking this concept to mean “making your data work for you.”

Ownership of data is a hot-topic. Consider how much Google knows about you. The focus now is keeping legal ownership of data to the individual so that it can be bought and sold. The benefits available to us here are in the form of cash.

I think before we even talk about buying and selling data, we should be asking how our data can work for us. Buy a man a fish…

Is Data Analysis better left to the major players?

Yes and no.

Yes because not only would they have extremely sophisticated data analysis methods, but they have access to a wide range of data. Wider than you. How much can you learn from the data of one person?

No because they can’t possibly tailor their results to each individual need and purpose. And you don’t only have your data. You could have access to your workplaces data – which is enough to learn about your workplace.

This is a question of scale. Enough data is required to provide context in order to draw conclusions. Maybe you only have the data available from a single model of a single project. Now, you’re just talking about scale. Having access to data from more models may mean better data and conclusions but it can also mean more noise. It’s all about the scale you are looking at.

Why am I talking about data?

A BIM Model is essentially a big database. Modelling is a way of putting information in and creating drawings and schedules is a way of getting information out.

The data we have in this database can teach us many things and we could probably do a lot with it to understand more about our projects and business. In this context I am concerned with how it applies to Agile.

There are several activities in a Agile/Scrum environment when we ask ourselves questions about what we are doing and where our data could help us:

Daily Scrum: What are my roadblocks? What is preventing me from working?

Review: How accurate is the work we have done? Was the brief correct? Is the client happy?

Retrospective: How are we working? Are we working smoothly? What could be improved? Are we efficient?

How Does Data Help?

There are many ways in which data can help these processes.

For a Daily Scrum example, consider: What are my roadblocks? The data we might want could be:

What have been the roadblocks in the past ten projects?

Perhaps they can be foreseen and addressed before they begin to hold up work. Or, maybe the data we are after is:

What did we do in the past ten projects to remove these roadblocks?

Perhaps there is a process here that could be automated, or at least made standard?

For a review example, consider: The S-curve of project resourcing is well-known (starting with fewer resources while works ramps up to the full team and then resources dropping away at the end). What if we could pinpoint times where we are more frequently performing incorrect or abortive work. When the team ramps up and more people join, are we more likely to stray from scope and requirements? Or, is it at the end when people with project knowledge leave the project? Data could help us pinpoint these items and focus our energies on such dangerous areas.

For a retrospective example, consider: How long did it take to produce our details? What about this project compared to the last ten? What were the processes that worked on our most efficient project? Do we spend more time on details of particular building typologies because they are less well-known in the office? Can we predict additional resourcing for projects that have characteristics that make them time-consuming to detail?

Maybe a good project manager could have these things in their head, but data makes them concrete, accurate and verified. It is very easy for those managing projects to get impressions that do not match reality – for example When More Pain is Preferred to Less. Too often in the construction industry more pain is preferred due to habit, perception, splintered teams and insufficient know