If you look around the web for the term "Progrestination" you will find a number of different definitions. It is a term that we use quite a bit when it comes to managing projects in the public sector.
For us, the term is defined as:
Progrestination n. (pro - gres - tin - a - shun) - Creating the illusion that something is progressing nicely when actually it is stalled or going backwards.
For example, when required to provide an update to my team on how our data migration project was traveling, my reply was "... the project is currently in an advanced stage of progrestination and is tracking well against stage goals...".
In other words, we are waiting for senior management and elected officials to say the magic words that will empower the project with what it needs to undertake the work (i.e. resources, money etc).
We are being told that this data migration project (and its parallel migrations being undertaken at the same time, care for a resource conflict anyone...?) is of the utmost importance and priority to enable our organization to become a unified entity. While at the same time being stalled for commitment of, well, everything.
So there we have it, the project team are currently in a heightened state of "hurry up and wait!"...
Project Impact:
Staff Morale
The mixed messages from senior management have the tendency to cause angst in the wider staff population. There is a feeling that the project team are not doing anything with the project.
Project Momentum
Any momentum we were able to create has all but gone.
Project Schedule
This project has a definite end date but the start date is being delayed. May need to review other project tolerances to find areas of compromise that will allow the project to be delivered on time.
Showing posts with label Project Planning. Show all posts
Showing posts with label Project Planning. Show all posts
Jul 19, 2008
Jul 4, 2008
Project Momentum
I guess most of you who have been following the previous posts have been wondering when we are going to get down and dirty with some data migration action... Well, not just yet I'm afraid. Is this not a blog dedicated to managing data migration? I hear you ask...
True, true, however the reason we are lacking in the data area is simple; it comes down to momentum. When dealing with a large scale project like ours, never under-estimate its power.
So far in our project, we have been trying desperately to follow sound PRINCE2 project management practices but unfortunately our organization does things its own way (often, it would seem, in spite of any reasonable logic).
We entered the Starting Up A Project (SU) process a while ago and had we waited for everything we needed (according to PRINCE2) before moving on, we would still be sitting in the SU processes. The problem lies with our senior management structure and although I like to blame them (as much as possible in fact) the issues are understandable and, to be honest, expected.
In a previous post I explained our very new and widely dispersed management structure which is only just finding its feet. This has meant that although we have the go-ahead for the project, we are having difficulty getting anything else from them.
PRINCE2 tells us that all projects need a Project Board from which the project manager takes high level direction for the project. This is especially important for us as the project manager (aka yours truly) does not have the authority to do things like commit resources from the business, commit budget funds or set enterprise level priorities. Although we have hassled senior management to get their act together, they have to sort themselves out first (there's power structures to be built and reinforced don't you know...). At this stage we have a headless
project.
We made the mistake of waiting for senior management to catch up with our fast passed schedules and in process we have lost some project momentum. People in our organization got a taste when the project was first mentioned (dare I say, even a little excited!) but because we were not able to follow up on that initial interest, we lost some focus and attention.
However, all is not lost.
While trying to get through this stalled period, the Project Team have been madly working through the Initiating a Project Stage and many other areas (PRINCE2 purists will be horrified) taking into account what we know and making assumptions left, right and centre.
Basically we are not prepared to simply sit and wait. What we hope to do when management get their acts together, is to flood the organization with our massive wave of project planning. Before they realise it, they will be swept up in the project and we will have our momentum back!
Project Impact:
Project Planning - Positive
We have used the delay in managerial decision process to gain more planning time that may not have otherwise been available. Extra time is spent on solidifying our communication plans to ensure the momentum is regained.
Project Planning - Negative
As we are currently 'headless', our planning in some areas has been based on assumptions or tentative schedules. These may very well turn out to be invalid further down the track.
True, true, however the reason we are lacking in the data area is simple; it comes down to momentum. When dealing with a large scale project like ours, never under-estimate its power.
So far in our project, we have been trying desperately to follow sound PRINCE2 project management practices but unfortunately our organization does things its own way (often, it would seem, in spite of any reasonable logic).
We entered the Starting Up A Project (SU) process a while ago and had we waited for everything we needed (according to PRINCE2) before moving on, we would still be sitting in the SU processes. The problem lies with our senior management structure and although I like to blame them (as much as possible in fact) the issues are understandable and, to be honest, expected.
In a previous post I explained our very new and widely dispersed management structure which is only just finding its feet. This has meant that although we have the go-ahead for the project, we are having difficulty getting anything else from them.
PRINCE2 tells us that all projects need a Project Board from which the project manager takes high level direction for the project. This is especially important for us as the project manager (aka yours truly) does not have the authority to do things like commit resources from the business, commit budget funds or set enterprise level priorities. Although we have hassled senior management to get their act together, they have to sort themselves out first (there's power structures to be built and reinforced don't you know...). At this stage we have a headless
project.
We made the mistake of waiting for senior management to catch up with our fast passed schedules and in process we have lost some project momentum. People in our organization got a taste when the project was first mentioned (dare I say, even a little excited!) but because we were not able to follow up on that initial interest, we lost some focus and attention.
However, all is not lost.
While trying to get through this stalled period, the Project Team have been madly working through the Initiating a Project Stage and many other areas (PRINCE2 purists will be horrified) taking into account what we know and making assumptions left, right and centre.
Basically we are not prepared to simply sit and wait. What we hope to do when management get their acts together, is to flood the organization with our massive wave of project planning. Before they realise it, they will be swept up in the project and we will have our momentum back!
Project Impact:
Project Planning - Positive
We have used the delay in managerial decision process to gain more planning time that may not have otherwise been available. Extra time is spent on solidifying our communication plans to ensure the momentum is regained.
Project Planning - Negative
As we are currently 'headless', our planning in some areas has been based on assumptions or tentative schedules. These may very well turn out to be invalid further down the track.
Jun 28, 2008
Setting the Scene - Part 4 - Business Process
It can be quite amazing to see how many different ways people can think of do the same thing, we are, after all, a naturally creative species. This is truely evident in our new organization when we look at how things actually get done and the differences between the original organizations.
Business processes will always evolve over time and are impacted by many factors both internally and externally, such as:
As we set out on our journey to provide a new information system platform, we find (as is often the case) that we first must address what the business does and how it does it. In many areas we find four ways of performing the same task.
In a perfect world, those of us who are custodians of the techology would be approached by the business with detailed plan, strategy, anaylsis and documentation on how they wish to proceed forward and we would say "Great, here's your system, have fun and let us know if you get stuck". In reality however, we find ourselves having to be catalyst for business process change before we can even start thinking about our system.
On a side note: We have actually been approached previously by a business unit who had their hearts set on a particual business system. When we started going down the project planning path and looked at the business case we were told "The system does everything that we want it to". Great! Couldn't be happier, until we asked "..so what is that exactly" and were told in all seriousness "Everything that it does". This logic will make you dizzy if you think about it too hard... But I digress.
Our destination information system has modules that cater for the majority of critical civic functions which means a wide and varied reach across the organization. Some business units are quite pro-active in their process change where as others may have other priorities or focus. This variation in attitude toward business processes forces our project to change from a straight data migration to a much larger business transformation project.
Project Impact:
Project Planning
Planning needs to expand overall scope incorporate products for business process transformation. These products dramatically increase the time required to complete the project as compared to a straight data migration project. It also increases the size of the project resource pool by now creating process workgroups.
Staff Morale
With this being a merger situation, there is resistance to change as many people fear they will lose the process that they have worked so hard to build and refine. The project needs to focus strongly on personal change management issues.
Business processes will always evolve over time and are impacted by many factors both internally and externally, such as:
- Management Strategy (or lack thereof)
- Management Reporting Requirements
- External Report Requirements
- Business Systems Utilised (or lack thereof)
- Personal Innovation
- Legislative Change
- Technology Change
- Business Growth
As we set out on our journey to provide a new information system platform, we find (as is often the case) that we first must address what the business does and how it does it. In many areas we find four ways of performing the same task.
In a perfect world, those of us who are custodians of the techology would be approached by the business with detailed plan, strategy, anaylsis and documentation on how they wish to proceed forward and we would say "Great, here's your system, have fun and let us know if you get stuck". In reality however, we find ourselves having to be catalyst for business process change before we can even start thinking about our system.
On a side note: We have actually been approached previously by a business unit who had their hearts set on a particual business system. When we started going down the project planning path and looked at the business case we were told "The system does everything that we want it to". Great! Couldn't be happier, until we asked "..so what is that exactly" and were told in all seriousness "Everything that it does". This logic will make you dizzy if you think about it too hard... But I digress.
Our destination information system has modules that cater for the majority of critical civic functions which means a wide and varied reach across the organization. Some business units are quite pro-active in their process change where as others may have other priorities or focus. This variation in attitude toward business processes forces our project to change from a straight data migration to a much larger business transformation project.
Project Impact:
Project Planning
Planning needs to expand overall scope incorporate products for business process transformation. These products dramatically increase the time required to complete the project as compared to a straight data migration project. It also increases the size of the project resource pool by now creating process workgroups.
Staff Morale
With this being a merger situation, there is resistance to change as many people fear they will lose the process that they have worked so hard to build and refine. The project needs to focus strongly on personal change management issues.
Setting the Scene - Part 3 - The System/s
Prior to the merger, we were four organizations with four individual business systems. We now need to be one unified organization with one unified business system. Sounds logical.
The business systems we are interested in for this project are the ones used to perform critical civic duties such as:
Our cause is helped a little by the fact that City of Atlantis and New Coast County used the
same system. Green Fields County and Red Mount County also used the same system bringing the source data structures down to only two.
The other positive is that the system selected to be used by the new Atlantis Regional County
is the one that was used by the old City of Atlantis and New Coast County. So our destination system is the same as one of the sources.
One might think that this is starting to look reasonably straight forward. Once you look under the hood of each of the systems however, it is soon apparent that the configuration of the systems is different in a many, many ways. This is even true for the two source data sets using different instances same business system. The systems themselves have been configured and enhanced around the differing business processes used by the original organizations.
Not a problem, all data migrations have some element conversion involved otherwise your not
migrating, your just copying. All we need to know is what the data structure needs to look
like in the destination system and we're on our way...
"So, business, what do you want this new system to look like?"
... and the silence is deafening ...
Project Impacts:
Project Planning
The project now needs to drive the business through designing the new system, the project is no longer a straight data migration. The differing data sets may require consultant resources from the vendors to assist with getting it right.
(In many organizations, this may be handled as a separate project on which the data migration project depends. Our organization doesn't quite see it that way... Advantage is that this is now within the control of the project team. Disadvantage is that it has at least tripled the effort required for the project).
The business systems we are interested in for this project are the ones used to perform critical civic duties such as:
- Manage property details
- Collect taxes
- Issue infringements
- Manage permits
- Take payments and issue receipts
Our cause is helped a little by the fact that City of Atlantis and New Coast County used the
same system. Green Fields County and Red Mount County also used the same system bringing the source data structures down to only two.
The other positive is that the system selected to be used by the new Atlantis Regional County
is the one that was used by the old City of Atlantis and New Coast County. So our destination system is the same as one of the sources.
One might think that this is starting to look reasonably straight forward. Once you look under the hood of each of the systems however, it is soon apparent that the configuration of the systems is different in a many, many ways. This is even true for the two source data sets using different instances same business system. The systems themselves have been configured and enhanced around the differing business processes used by the original organizations.
Not a problem, all data migrations have some element conversion involved otherwise your not
migrating, your just copying. All we need to know is what the data structure needs to look
like in the destination system and we're on our way...
"So, business, what do you want this new system to look like?"
... and the silence is deafening ...
Project Impacts:
Project Planning
The project now needs to drive the business through designing the new system, the project is no longer a straight data migration. The differing data sets may require consultant resources from the vendors to assist with getting it right.
(In many organizations, this may be handled as a separate project on which the data migration project depends. Our organization doesn't quite see it that way... Advantage is that this is now within the control of the project team. Disadvantage is that it has at least tripled the effort required for the project).
Subscribe to:
Posts (Atom)
