Knowing the size and shape of a thing is so fundamental it’s one of the first things we learn as children.
Whether it’s for a piece of work I’m about to tackle or a project I’ve been asked to review, how many things we have to deal with and their status is the first question I ask, not the methodology, not who is on the team or even how big the budget it is. All those things can only be assessed for their fit once the composition and size of the problem or task is known.
I’ve worked in the ICT industry for nearly twenty years: more than fifteen years as a project manager on a wide range of projects all with unique combinations of complexity, technologies, teams and politics. For a large number I’ve been called in because they need correction and what often leaves me aghast on lifting the lid is the number of times that the volume of change hasn’t been properly assessed.
Recently, I worked with a client to transfer all its records - stored in an electronic documents and records management system (EDRMS) - to other agencies. In five years of operation, this client agency had amassed nearly 900,000 documents each with an unlimited number of versions. One record we exported had around 200 versions of the same very large Excel document. Consequently, an export of a section of the file plan took many hours. Add to that process the manual audit check and an overnight encrypted copy of files for secure transport and it could take several days to get to the point where one agency passed the files to another. Then add at least the same amount of time for the receiver to import the files.
It’s not surprising that a request to transfer wasn’t something that could happen in the twinkling of an eye. What frustrated me was trying to make non-technical personnel and governance groups understand that the reason we could not complete all the transfers in the time given wasn’t a technical issue but a case of simple maths. There was really no reason for the typical “this is technology I don’t get it” response.
The same factors have existed for many web content migrations I have worked with. Particularly when it’s not a simple transposition of structure and content - and therefore automation is limited or infeasible - the human element comes into play. I know that a blog post or article will take me anywhere from forty-five to ninety minutes for a first draft. A business memo of around a page and a half will take forty-five minutes to an hour. So it’s reasonably easy to know that even a modest 100 page website requires seventy-five to 150 man hours to get through the drafting process alone, so long as everyone writes at my pace.
A restructure, rewrite and approval process for a redevelopment of most reasonably mature websites will take months even with multiple writers and migration personnel all working. Throughout the process, a frequent check of velocity is needed: x number at draft; y number at review; and z number at approved. Again: when the process will complete is a calculation and arbitrary deadlines will merely result in higher costs or poor quality.
Even if the project is a simple desktop deployment or an application development we are still prey to the numbers. How often is the time it will take to develop a piece of functionality not properly estimated? How often is the time taken to unpack 100 monitors from their boxes and plugging it all in not considered when a team is given only a day to roll out into an office? It happens often: far more than you would think.
In the physical world, we would never start building a high-rise without understanding how deep the foundations must go, how much concrete, steel and glass is required. Yet, it seems AOK to proceed with technology projects without quantity surveying.
Unfortunately, whilst all this seems to be very simple to understand, all too often I encounter project managers who can’t tell me how many items they are wrangling to deliver the project. They can’t articulate all the steps of the process and how long each is estimated to take. How are they surprised then that they are nowhere near finished?
My advice to customers, stakeholders, and governance groups is to test your project team’s knowledge of the volume. Test their understanding of the time it will actually take to get the job done: ensure they recalculate based on actual experience. Basic calculation can save a lot of stress.
It's not complicated; it doesn’t take a great deal of technical knowledge… After all it’s child’s play.
0 comments:
Post a Comment