- About
- Services
- Solutions
- Portfolio
- Contact
- Blogs
These past few months I have been thinking a great deal about the volumes of information that the team at DPCI can receive from customers throughout the course of any project. This information can be about the customers' business or functional requirements, their information architecture, system architectures, data dictionaries, use cases, technical specifications, site maps, wireframes, taxonomies, and so on. The form in which these wide variety of materials comes in can be MS Word, MS Excel, MS Visio, Powerpoint, PDF, email files, text files, printed documents, scans/JPGS, URL links to reference sites, and so on.
What has been on my mind is how much additional information we are often provided above and beyond the specific scope of any given effort. I'll clarify here that this isn't always the case -- quite frequently new customers really don't have any documentation at all and we've got to help them to pull it all together. What I'm writing about here is the case where customers have done much of the homework to define what they're looking for, then present that to us.
The challenge is that the materials can often be padded with an abundance of information that may distract or potentially be contradictory. Another challenge is that -- with the exclusion of comps and site maps which seem to be relatively standardized in the industry -- project materials that we get from customers sometimes do not follow a standard format for how the information should be represented. This tends to have the effect of adding to the work effort and increasing probability that mistakes will occur, since the team has to figure out a) where to find what information, and b) winnow down the document inputs to discover only the relevant information to the project at hand.
The idea should be to have a master checklist that references a set of materials that customers can use as best-practice guides for creating only those materials that are pertinent to implement the particular technology. We can all agree that there are always pecularities of any implementation -- particularly with regard to integrating content technologies with internal infrastructure applications or externally hosted solutions from 3rd parties. However, the anatomy of a Web content management project, for instance -- how it should be implemented correctly and what materials that are absolutely necessary to define what needs to be done -- should change very little from project to project.
In this way I write about being 'reductive' in project management. The PM -- and the functional and business analysts alike -- should strive to gather the most concise, germane information needed to document the plans that will be used to implement any technology initiative. Far too often we gather too much information, over-document, scribe every phone call, print every email. Those things can not only distract but actually cost rework, scope creep, cost and schedule delays and quality diminution since items are either misinterpreted or outright missed.
I am reminded of a famous quote by the famous French mathematician and philosopher, Blaise Pascal (who seemed to have liked being quoted in his lifetime): "I have made this letter longer than usual, only because I have not had the time to make it shorter." In fact, by creating volumes of documentation, project resources can convince themselves they are being thorough, when in fact they may not be applying the intellect needed to reduce information down to the essential elements necessary to get the job done.
I've recently challenged my technical services team to come up with a reduced set of checklists that reference templates and best practice guides to give to DPCI customers. These materials would support the initiation and planning components of the project management lifecycle for integration and development projects. This is not a small task, since we implement a wide variety of content technologies, ranging from Web content management to digital asset management management systems and beyond. The team is starting with Web content management since that seems to be the area where the most robust spending is happening in 2009.
I will keep customers and other interested parties informed here on my BLOG as this internal project progresses. In the meantime, if you have any similar experiences with 'reductive' project management, I'd welcome your feedback directly beneath this post in the comments section. Thanks in advance!
Posted at 12:43 am by Joseph Bachana