Parallel workflows: Preparation at a low-level, while management sorts things out at a high-level

Question

Introduction:

My organization is embarking on a corporate asset management project. The corporation knows that it needs to do comprehensive asset management on all its assets, in a single, easy-to-use data location. The idea is that asset-inventory data from several specialized systems will be periodically exported & imported to a single location, for the purpose of organization-wide analysis and reporting.

The Situation - High-level:

Management is currently in the process of figuring out:

1. What they want
2. How they want it
3. Why they want it

They're doing what they refer to as "starting with the end in mind". While I wouldn't say they are employing any sort of project management practices, they are trying to 'figure their poop out' at a high-level. This makes good-enough sense to me.

(This is a bureaucratic organization; it will take 1-3 years for this planning to be completed.)

The Situation - Low-level:

Down at the worker-bee level, a few of us are working on 'getting the organization's poop together'. In other words, we're preparing. We know that the details of the project are subject to change; heck, they haven't even been defined yet. But we have a general idea of where it's going, and we know that our data needs a lot of work to get there. And we know that we should start thinking about the framework that will be needed for this initiative.

The Question:

We generally have the support of our immediate management. They know that being prepared is smart, and we've been successful doing things this way in the past. But we face fierce criticism from other stakeholders. They accuse us of putting the 'carriage before the horse', and think that the details(data) will just work themselves out, when the time comes.

It's not that we think that they're 100% wrong (there is some sense to what they're saying), nor are we looking for help to argue with them. However, we would like to make some sense of this sort of parallel-workflow that's we've come up with, so that we can refine it and communicate it better.

It could be visualized something like this:

Project Planning             Project is underway          Project Complete
---->---->---->---->---->---->---->---->---->---->---->---->---->---->----|
                             ^
Preparation                  |  
---->---->---->---->---->-----
                              \
                               Implement! Hit the ground running.

So the question is:

Does this fit any sort of project management technique? How would it be described?

Answer 1

This is a trade-off question. It makes perfect sense to prepare for a project. Take a simple project such as upgrading your kitchen. Even if you haven't chosen what the new kitchen will look like, which may include semi major plumbing changes to move the sink from one wall to another, and so on. You may choose to prep that area by trashing or selling items you know will not survive the upgrade, if for no other reason but to make the space ready for work and maybe drive the project costs down.

In your work setting, where other stakeholders are complaining about the prep work, this may be more a function of what is being traded for those tasks, i.e., what work is being deferred and delayed so the prep work can occur by those employees. And then it becomes a cost / lost revenue / delayed objectives analysis.

So you are at the stage of building a case for the prep work, which includes capturing the benefits of doing so which may include decreased project costs or risks. But then you need to know what is being deferred, how that deferred work is impacting those other stakeholders, and what other opportunity costs you are paying in exchange of the prep work. It is a business case that you need to build, show that the plus is greater than the minus, and then go sell it.