When I created this blog, I went through the usual diligence of deciding on an approporiate name. When I thought of Project Notebook, it seemed about right. It was to be my collection of writings and articles, and eventually the collection of writings and articles by others. While not the most important factor, I also investigated how it would fare in search engines. It had an OK ranking.
Today, the search term "project notebook" returns my site at the top of the Google results (just below shopping results for project notebook). I've been monitoring how people come to the site, and more often than not, its because they are seeking to find what a project notebook is. I think its high time I put my thoughts about the topic into this blog. Keep in mind, I've never seen an official definition of project notebook in any official project management books or sites. But over the years, I've worked with many who seem to have a common understanding of what a project notebook should be. So let's take a look at where we've been, and where I think we're going with project notebooks.
I first started keeping what might be called a project notebook in the 1980s. At the time, it was usually just to hold requirements, designs, and other documentation for projects I was working on. There really wasn't much organization. It was strictly paper. I did start using a PC with word processing once one of my dual floppies was replaced with a small hard drive, but dot matrix printed paper was preferred over the green screens.
By the 1990s, I was a project manager for client-facing projects. These had a bit more structure -- the contract, requirements, design, but more formal documentation, organized by project phase. It was around 1997 that I first started organizing my notebooks around the methodology and also making them deliverables to clients. The notebook was delivered at the start of the project, and contained the contract, key documents describing the product, key decision making documents, and tab placeholders for the future project deliverables.
By the end of the 90s, as I started to work for Cambridge Technology Partners, we started keeping the documentation for large software implementations organized in folders on hard drives. By this time, there was an extra twist -- at the end of the project, the folders were zipped up and sent to become a part of a knowledge base. If I needed a project template, sample plan, or anything related to our type of enterprise software projects, I was able to find them online.
The Siebel Methodology (circa 2001) took the project notebook concept to a new level. We broke our hypothetical best-case implementation plan (roughly 600 tasks) into multiple project phases. Each task in the plan was ultimately to have a tool, template, guidance, or other asociated artifacts to assist with understanding task completion. These were all available on a web site. On a quarterly basis, the content updates were downloaded to a self-extracting CD. New project managers simply popped in the CD and a series of project phase folders, including all the tools and templates, placed itself on the hard drive. Once again, as the project finished, the contents were zipped up and forwarded to a knowledge manager. As we developed the Siebel Estimating Tool, we had a treasure trove of project plans to validate it with. About the same time, another consulting and services delivery company called their verion of this "PMO in a Box".
In a sense, the Siebel Project Notebook had a notebook within a notebook. One of the artifacts available for use was a multi-sheet Excel workbook with placeholders for budget, milestones, issues and risks lists, communications plans, resource plans, and more. For smaller implementations, that was often enough of a notebook to manage the project.
These days, as a manager, I tend to like the Boorum & Pease hard cover notebooks (you can see mine on the blog header image). I still tend to give my clients project notebooks, but I'm finding fewer and fewer of them tend to use the material beyond the implementation meeting. With green initiatives, project notebooks are ready once again to go to new levels.
My current vision of the (hopefully not too distant) future is a collaborative workspace on MOSS or a similar platform. Folders of key project information would be pre-populated. There might also be a Wiki for capturing project knowledge. Sharepoint would be augmented with a project management tool such as SMART EPM from LMR Solutions . Clients would have access to their project workspace to see project schedule and budget progress, as well as tap into the stored knowledge. Project time would be captured directly from project plans and feed directly to our corporate finance platform for billing and reporting. Data files for ETL would be exchanged through web services. More importantly, I would be able to create a dashboard view to see a stoplight snapshot of all projects. Clients would be able to collaborate on requirements, get needed information, and much of the required administrivia would be handled by automated interface.
So what is the future of project notebooks? Maybe there is a role for collaboration in cloud computing? Only time will tell. In the meantime, if you have further questions about project notebooks or The Project Notebook, please don't hesitate to comment below or drop me a line at sdcapmp@aol.com.
No comments:
Post a Comment