With the initial development models like waterfall, documentation was a critical component of the project to both define and manage scope, gain agreement on design, and eventually determine if the solution met the requirements through the testing phases. We as project managers used documentation as the vehicle to gain alignment with the community who needed the solution. This trend has continued with the introduction of commercial software who provide a shell into which implementation teams enter meta data to tailor the commercial software to the unique needs of the customer. Even today, with the introduction of web applications leverage Software as a Service (SaaS) or cloud-based offerings, documentation is a common component.
Documentation remains a good mechanism for recording how commercial software was implemented; the meta data entered to tailor the solution. For the worst disaster recovery scenarios where the solution must be rebuilt, this documentation is the foundation upon which disaster recovery plans can be built. Documentation of test cases and the test management controls associated with a firm set of test cases enable project managers to track testing progress and answer the two main questions: Are we on schedule? and when will we be complete?
As SaaS and cloud computing become more popular, these vendors maintain multiple backups of the environments and offer embedded disaster recovery not before seen with on-premise implementations. The worst disaster recovery scenarios noted above are not as relevant as before since the vendor is covering off on this conditions. Furthermore, many of the vendors such as Salesforce and BigMachines offers integrated development environments (IDEs) with the cloud-based offerings so the documentation of designs and code can occur within the IDE and be backed up using the same mechanisms as the transactional data. Even with on-premise implemenations, nightly backup can occur to simulate the same offering of the SaaS or cloud-based offerings.
Looking even further back into the development processes and considering the newer agile and prototyping methods of development, we can begin to question if detailed designs and even traditional requirements are a necessary and critical component of a project in today's world. With these methods, the detailed design evolves as the users gain experience with the solution, exercise their business processes within that solution, and fine tune the design. With the agile models, defining the contents of each sprint continues to make sense as this information is not typically captured otherwise and project teams can utilize the multitude of agile management tools like Version One to streamline the documentation efforts. At this point, some people may be claiming heresy as this discussion is questioning the well seasoned methods of scope definition and control. To some degree I agree as eliminating all documentation does not make sense to me. Can we critically look at the volume of documentation we perceive is needed and look to repurpose this capacity to delivering additional functionality to our customers?
For example, when two disparate groups are working on a common solution such as with an interface, then a interface design may make sense. This can especially be true when working with two groups each with their own contract. In order to confirm proper contract execution, the definition of the work through an interface design makes sense. If we look at the same example and remove the contract constraint, the need for an interface design document may be different.
Even the documentation of code or an architecture could be questioned within this same context. If we adopt the newer agile methodologies and do not have contractual constraints that drive the need for documents, do we really need documents on our projects? Historically, these documents have been a mechanism to reach agreements but if we use close coordination such as what can be achieved with a scrum meeting or other frequent coordination forum, projects today can drastically reduce the need for documents and free up this capacity to build more functionality.
As we look at the risk profiles on our projects and build our project plans, we can and should consider when formal documentation is needed, when we can achieve tighter coordination through more frequent face to face (includes electronic through Webex or GoTo Meeting like products), and focus more energy on building more functionality for our customers.
Comments