A number of years ago (ok, it was way back in 2011) I got to co-deliver a paper at the Oracle Application Users Group called “Stop the Madness”. The paper was about how organizations who use Oracle Projects deploy multiple timesheets and we showed how our TimeControl product could avoid that. Obviously no one makes a plan to deploy multiple timesheets and that still happens but lately I’ve been thinking about all the other ways we see organizations doing something that sounds fine but ultimately makes them less effective rather than more.
So here’s some of the most common business challenges we are asked to help with.
We’re pure Agile
This has become a popular refrain over the last 25 years. With the birth of the term Agile in the Project Management industry we’ve heard from more and more organizations that they are trying to become “Pure Agile” It’s mostly pure nonsense. I don’t have anything against Agile. HMS has worked as an Agile organization almost its entire existence (and that predates the Agile movement). The Agile concept isn’t at all new but after the year 2000, it became a rallying cry for programmers and technology-centric users at the tactical level and the promotion of the concept has become stunningly successful. Even the PMI has shifted its focus to make all projects “iterative”.
But, when I encounter an organization who starts their conversation with me with “We’re Pure Agile.” I have to pause. “That’s great, I’ll reply. So where do you get your project budget from?” The answer is almost always “Oh, that’s handled elsewhere. “Ok, I say. How about your backlog?” (a good Agile term). “Where does that come from?” Um, not sure,” is almost always the answer. “Ok, how about the size of your team,” I ask. “Do you determine that yourself or does that come from elsewhere also?”
It turns out that almost universally when an organization says “We’re pure Agile” what they’re referring to is the team-level or tactical level of the organization. Project Management and Portfolio Management is still happening, just not by them. It’s happening at other levels of the organization and the execution of the projects in question are, perhaps being done using an Agile process.
Again, no problem but not, obviously, pure Agile.
When we have people realize this, it opens up the process to includes the other, almost certainly critical, elements of the project management process.
Not everyone is happy to include other parts of the organization in their Agile project management deliberations. After all, that means thinking of constraints like when will you deliver what you’re building and what is it costing us for what you’ve built so far. Most classic Agile deployments focus only on what tasks did you complete and what is in the current sprint.
Management would like more.
Tracking is not at all important.
It’s one of the things that has fascinated me since my earliest days in project management. Project Managers are presumably put into place to manage, right? After all, if we didn’t care about when a project is going to be finished or how much the project will cost, what is the point of a Project Manager? It’s because life does not typically go according to plan that a Project Manager is useful.
But, time and again, I encounter project management environments where there is planning but not tracking. Agile doesn’t help this either as Agile doesn’t tend to think about the original project schedule or project budget and then compare against the original plan but Agile isn’t the cause of this syndrome.
Years and years ago I can remember being in a large conference of a multi-national bank in New York City. I was discussing deploying our TimeControl timesheet system and we had come to the subject of updating tasks with the timesheet progress.
I was stopped in the middle of my explanation by someone who turned out to be one of the top Finance Executives at the bank.
“I don’t understand something,” he said. “You are saying that the timesheet updates the tasks but that there must also be an indication of how much effort is left. Why can’t your TimeControl just update the task automatically based on the hours?”
“Well it does update the task based on the hours, I responded. But what would you expect TimeControl to do to the task if there was a plan of 40 hours and TimeControl had determined that 40 hours had been spent?”
“You should mark it as complete,” he responded.
“Ok, but what if it’s not,” I said.
“That’s what I don’t understand,” replied the executive. “If there was a budget of 40 hours and the workers have spent 40 hours then that task is done.”
I was dumfounded and didn’t want to start correcting such a senior executive in a room with 30 people around the table.
Fortunately I was rescued by the CIO who pulled the Finance executive out of the meeting to explain that life doesn’t always go as planned. The CIO returned. The Finance executive did not.
So many people assume that once the planning is complete, life will go that way but when you think about it on literally any project, that’s a fantasy.
This is why tracking the project is essential.
In our own organization we’ve been caught with this ourselves. A number of years ago a programmer started working on a task that they found more complex than they expected. The original budget for the task was 4-8 days but at the end of the current sprint they announced that they “weren’t quite done” and the task rolled over to the next sprint. At the end of that sprint, once again they “weren’t quite done” and the task rolled over again. We weren’t tracking and the task rolled over until we were at 14 weeks of work. It was a project management failure. The programmer was simply out of his depth on the task and was unwilling to put their hand up and say so and because we weren’t tracking he spun his wheels making no progress week after week until finally the accumulation of non-performance was revealed. We implemented a different tracking method after that.
Project Management cannot integrate with Finance
We hear this all the time. With a TimeControl deployment we are often arriving to face this kind of challenge. If we’re there in person, a group around a conference table will often have several Finance people on one side, several Project Management people on the other side and the IT people near the end of the table.
It’s not at all uncommon to find that the Finance people and the Project people have never actually met.
The meeting will often have been pulled together by the IT management who explain that the entire organization cannot continue to support multiple timesheet systems.
The costs of that inefficiency was the subject of our “Stop the Madness” presentation back in 2011. There’s a huge incentive for IT to reconcile the needs of the organization and use a single source of timesheet data. To be fair, Finance has that incentive also as the cost savings can be significant. But, once Finance has their ERP system deployed and stable, there is a huge reluctance to change.
And that’s what we face. Project Management has to be able to track tasks. They also have to report costs. But the structure they hope to use for both is faster and has fewer controls than what Finance uses so there’s a trade off to be managed.
For project management to use a multi-function timesheet like TimeControl, they are going to have to accept that there will be more controls to make the system more auditable. That’s a drawback for them. But, the benefit is that project personnel won’t have to enter 2, 3 or 4 timesheets each week.
Plus if multiple timesheets are being used, there will be a churn of effort each month trying to reconcile the hours from the project system, the billing system and the payroll system. For anyone doing that now, you know it’s a miserable exercise that produces no productivity.
For Finance, change is to be avoided. But Finance too has benefits of getting one version of the truth. This is a massive improvement when an audit occurs and Finance is called upon to explain the costs of what the organization is building as they must do for R&D tax credits or SOX compliance or DCAA contracts.
The alternative of having every project task loaded into the ERP timesheet system is almost always rejected by Finance. “We can’t pollute our system with that level of detail,” they say. So a multi-purpose timesheet which can feed Finance on once side with auditable results and project management on the other side with project progress seems a possible solution.
We cannot deploy until we have an all-inclusive all integrated Big Bang
I’ve talked about the Big Bang theory of deployment vs. a Phase theory for years. Here’s one of the articles on EPM Guidance about it (https://www.epmguidance.com/2009/01/17/article-big-bang-or-phased-approach/).
The Big Bang approach was, some 25 years ago, what prompted the Agile Industry. Everyone wants to make a completed, working, all-inclusive solution. Everyone. But the method you use to get there carries consequences. We continue to see organizations challenged by this today.
If you go with your Big Bang approach, you will make a global design for your system. You will talk to all possible stakeholders who will give input. The design will be a significant effort. Once you’re done with the design, then you will start doing the work to pull together the different tools you’ve identified and create the system you’ve designed. That will take effort, perhaps months of effort or a year or more. Once you’ve got the system created, then all the stakeholders will have an opportunity to review the new system and give input. It is a 100% guarantee that there will be changes demanded. Then the system will be changed, taking again weeks or months. Then the stakeholders again will have to regroup and be advised and give feedback. It’s almost certain that more changes will be required. Then the testing phase will be significant. After all, the current systems being used for this all-inclusive change will all be affected.
During this entire exercise, there are costs but no return on investment. None. The technical team doing the work is often sidelined as the work is complex and interruptive. So the team gets resistance for any work that goes outside the team for feedback or assistance. That just extends the exercise.
If it’s successful, the end project is delivered in a “Big Bang” on a given day and all systems shift over to the new system.
But it is not certain that this will ever happen.
While the all-inclusive big bang project is being created, things can happen. Personnel will change. The team might change with corporate knowledge lost of the design decisions made. The company could be bought. The company might buy another company. There could be reorganizations. The business might go in another direction. The funding could dry up. Any of these kinds of challenges will result in a project that had only costs and no benefits.
Sadly, this continues to be a strategy for some.
We are much more in favor of a phase approach. A bit like Agile thinking we see a benefit to getting the system underway with the least amount of requirements handled that still makes a viable system. The feedback becomes a continuous loop with improvements and the adoption of more functionality along the way. Is it perfect? No, of course not. But there is return on investment almost right away.
A phased approach has to ask “What is the minimum amount of functionality we can deploy, the deployment of which would be sufficient that we would not abandon the system?” That’s a completely different kind of thinking from “What is the most this system can do and how do we go even further before we deploy?”
Ultimately a phased approach is much lower risk. Our technical staff continually encourage the system to “get into production”. We know that no matter how much theoretical work is done in the design, once staff are actually using it, there will be requests for change.
The risk with a phased approach is perhaps you never get to the 100% goal of all the functionality you originally envisaged. Maybe you get to 80% and management says “You know, that’s good enough”. But, even 80% means you’ve returned 80% return on investment from the original goal and you started to return that investment quickly.
Is that all the madness?
Of course not. These are just some of the most common project environment challenges we encounter. If you recognize yourself in one or more of these, don’t fret. You’re not the only one.
But, know that if you are encountering these kinds of challenges, they are solvable.
