In our business we are often asked if data from one system can be integrated to another. There’s almost a pull for people to say “If I can integrate it, I must”. That’s just not true. Let’s look at an example where integrating might cause a negative impact.
Years ago I was asked if I could integrate project scheduling data with Outlook.
“Look,” said the client who was an IT specialist, “Outlook task data looks just like Microsoft Project Task data. We could integrate them, couldn’t we? Then, we could have a top-to-bottom view of data where every change recorded in Outlook rolls up all the way to the portfolio view of the senior management. It could provide real time updates that flowed across the entire enterprise.”
This sounded like a terrible idea for me but I didn’t want to shoot the idea down in flames.
“The movement of data back and forth is quite straightforward,” I said. “So from a technical standpoint, yes we could integrate but before we do, let me ask you a couple of questions,” I said.
“What will happen to an individual’s availability if at the end of the day, they book themselves as unavailable for tomorrow morning because of emergency dental work.”
“That’ll work great,” said my contact. “No one will book them tomorrow morning because they will know the resource is unavailable.”
“Ok,” I replied, “but what about the tasks on which this person is already working? Let’s think about a task that they were to work on and complete tomorrow at the end of the day. It’s listed in your project schedule and now, I presume the task will have to slip a half day, right?”
“Hmm. That’s right,” my contact said, thinkingly.
“And, I went on, “what about any task in the future that had a dependency that could be traced back to this task. They too would have to slip a half-day, right?”
“Umm Yeah. That wouldn’t be too good,” my contact said, now a little less enthusiastic.
“What about the executives at the top” I continued. “If the task that this resource is on the critical path and is now delayed a half day, might that push a future project’s start date a half day later?”
There was a long moment of silence.
“I can see it now,” my contact replied at last. “So we could integrate but in this case we shouldn’t. But it looked like such a natural fit.”
The problem for my client is that while the data may look very similar, the context of the data is not similar at all and if you’re a technical person, you can get caught up in the movement of the data of one aspect of a product and forget that it’s part of a much more complex system.
In our own timesheet business with TimeControl, we’re occasionally asked why TimeControl doesn’t keep project totals in a project control system up to date throughout the day as results come in.
“First of all, what would you do with data that hasn’t been approved?” we ask.
“What would you,” we ask, “if, while the timesheet is still in draft mode, a user entered 88 hours of work on that task instead of 8 as they intended and as they will sign off on at the end of their day?”
We look at data and often forget that we have numerous assumptions about it. We look at a project progress report and we have a basic assumption that somewhere up the line, someone has looked at this data and approved it. We look at project progress and we assume that the project manager is prepared to stand by the data we’re looking at and be ready to explain it. Even though the timesheet data looks like it’s ready to be task progress data, we have more process around it than just moving one field in one table to a field in another table.
We have similar problems when we look at project data from different levels of the organization and organizations that have attempted to deploy enterprise project management across their enterprise have determined that it takes more than software and a database to make that happen.
In our own development department when working on our new TimeControl Project we now tend to think of project data in at least three levels.
At the Strategic Level we know that executives have a long range perspective that is at least a year and possibly more. They are thinking of current projects and current deliverables but also future projects and future directions that may not even be a good match for their current resource expertise. Unless they’re asked, senior executives don’t want to see the day to day schedule or an individual’s workload.
At an Operational Level, project managers, program managers and, resource managers are all working to take the priorities of the executive suite and deliver on them. These managers have a perspective that may be only weeks or months long. They are looking to create the list of tasks that need to get done and, where it’s important, sequence those tasks. Unless there is a problem, project managers have little interest in the long term portfolio goals or an individual’s workload.
At a tactical level, team leaders and individual employees have a perspective of a much shorter time. That may be just a shift long or perhaps a week long. They are looking to take tasks that have been defined in the queue and get them accomplished in the most effective manner possible. Individual workers have little interest in the overall portfolio of projects or the schedule for next week or next month or next year. They’re busy getting the work done for this week.
Yet, looking inside a database, the task data for all three of these levels looks very similar. There is a huge temptation to say, “It should all be together!”
In fact, having each of these levels be distinct and either completely separate or much more loosely tied is by far more effective. Even the views of the data may seem similar but won’t be used in the same way. A team member has little use for a cost curve. A project manager doesn’t need to see a Kanban series of boxes by person. A Strategic level executive doesn’t need to get a barchart of 10,000 tasks.
Each of those levels of the organization deals with more than just the data. They each have their own process that is designed to make their level most effective. It’s easier to think of each level as a complete system which interacts with other systems rather than a collection of data.
So focusing on the business needs at each level can result in a different perspective on tools, process and even data.
Sometimes it’s better to look integrated than to be integrated.
