There's a
posting I recently read about the "impossibility" of doing project management with spreadsheets. Indeed, no less than six reasons are offered up.
Nonsense!
I've done many successful projects with only a spreadsheet, and many I know have done the same thing.
So, what are these six reasons, and why are they nonsense?
1. Risk of error
Spreadsheets are error-prone; though they are easy to use for statistical calculations, they are not databases.
W
ell, it's not just statistical calculations, it's calculations for all applications. Try using a database language to do calculations... not the easiest thing.
Errors? Well, of course, there are data entry errors, data overwrite and retention errors, and data retrieval errors. A database is no more attuned to these maladies than a spreadsheet. Indeed, data qualification can be written into the criteria for a spreadsheet cell just like it can for a database record
2. Lack of security
Security is another important point when dealing with spreadsheets. There is no comprehensive solution to the spreadsheet access issue. Not everyone in the team should have access to the files
The author has a point about security. Although there is no comprehensive spreadsheet solution, in fact on most large databases many users have access to both view and create/delete. So, whereas the controls are there, they are largely open to abuse.
3. Nearly no teamwork, collaboration or communication
Planning, forecasting and project management in general involve lots of collaboration. It’s natural for team members to communicate, discuss things, make decisions, plan activities, change goals, alter deadlines etc. Normally two, three and even more departments are involved in the sharing process.
How do you see that collaboration working using a spreadsheet? Is everyone going to update the same document and then email it to the rest?
Work collaboratively in the same document? Yes. Email it around? No! My goodness, those problems were solved years ago.
4. Loss of key information
This comes as a continuation of the point above. When I say, ”sharing,” I mean being able to edit and comment on one document at the same time.
One more unpleasant thing I noticed when I worked predominantly with spreadsheets is that the same information may appear in the same document twice because people are reluctant to delete information “in case it’s useful in the future”. This results in confusion.
You know, when you do a project and notice there are a dozen or more database instances so that there can be experimentation, development, test, and no loss of previous data "in case it's useful in the future" you might wonder if that would be any more burdensome with spreadsheets. The fact is: a database and a spreadsheet are both applications on top of data records. The impulse to not lose anything is the same in either case.
5. Tracking becomes super-difficult
One file is not enough to store everything about complex projects. But multiple files and folders may make it nearly impossible to track the progress of the project.
I understand that project managers must track the status of things but spreadsheets will hardly ever let you do that.
Yes, industrial strength databases can be effective even with millions of records, whereas spreadsheets are usually constrained to a fraction of that number. So, if your PMO requires millions of records (Lord help you!), you probably should be using a database
6. Poorly managed project history
Spreadsheets just fall apart so much that you cannot figure out how things are interconnected unless you’re working with them day-to-day. Because deleting things may have dramatic results; people colour in unnecessary data, then they use other colours to highlight important information. It’s meaningful in the moment, but a month later no one understands a thing.
Well, you can't have #5 and #6 at the same time. Database schemas can be every bit as daunting as spreadsheet logic. If you are going to have millions of records (#5), you might have hundreds, if not thousands, of tables; and thousands of data points to keep the records unique, so say nothing of the logic of normalization.(#6)
You have to wonder if the guy who wrote this stuff every got beyond a desktop database.
Read in the
library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
