Planning can go on and on, but sooner or later, you have to complete the planning phase and move on to execution. That said, I still have a bit more to discuss about planning because I believe its importance cannot be overemphasized. I have had a lot of experience planning for execution, but what lessons learned has shown me, you also need to regard your project planning as prevention planning. Phrased another way, negative experience teaches you to plan for what you do not want to occur again. Even if you don’t have much experience at prevention planning, established project management planning practices such as procurement, quality, and change request and creating RFPs are very effective for prevention planning. Creating RFPs can be arduous, but I quickly learned that the effort exerted in creating a meticulous RFP made creating comprehensive contracts easier.
When project meeting discussions diverge from the original project plan, and in particular changes to scope, a phenomena occurs where requests made during those discussions become expectations. If those expectations are not managed properly, scope creep ensues. During project meetings, an experienced project manager will quickly deflect discussion of items not included in the project scope towards the change request process. Lacking a change request process, team member consensus can, and usually does, expand the scope of the project. In addition to the change request process, a solid defense to scope creep is a well written contract. The contracts I agree to must have clearly defined acceptance requirements and clearly defined milestones that determine when invoicing and payment are to occur. With Milconn, it was the iron-clad payment agreement that allowed me to go against my better judgement.
My contractual agreements with companies typically originate from the RFP. In the RFP, the work to be performed is described in ample detail. Because the content of the RFP was thoroughly evaluated and eventually accepted by the procurement process, it is a easy step to transfer accepted RFP content to a contract. In a contract, I prefer to specify payment terms based on milestones and acceptance criteria not on specific details such as those found in the WBS. An important goal of the contract is to not be contractually obliged to deliver scope changes unless acceptance criteria and additional cost are clearly defined and agreed upon. Consequently, the contract becomes a shield against scope creep. Unfortunately, you won’t be shielded from the pressure applied by project managers and other senior team members to address additional functionality. That type of coercive pressure exists in most enterprises, but the contract permits you to disregard the threat of nonpayment. The procurement process is wickedly emotionless, so once you satisfy a set of criteria that guarantees payment, the procurement process sets payment in motion in a manner that is nearly impossible to halt.
In addition to scope details, quality metrics should be clearly defined. These metrics are placed directly into my contracts for smaller projects and in contract exhibits for larger projects. Quality is very subjective, but nonetheless, quality requirements can be readily described when you follow the ISO definition, “quality is the degree to which a set of inherent characteristics fulfill requirements.” As a software designer, you get plenty of practice stating what a particular process is going to accomplish, and that is pretty much your quality requirement. Consequently, moving a statement describing what you are going to accomplish into a contract becomes as easy as cut and paste. When it comes to quality, there exists a myriad of aesthetic attributes that one must consider. If aesthetics is a consideration, I place the burden on the client to describe what they want and to provide the metrics. It really isn’t safe to anticipate a client’s subjective expectations.
As I mentioned at the start of this blog post, planning can go on and on, so you need to manage your time spent on project planning. The amount of time spent requires balance between describing too much and not enough. Detail is a key indicator. If you are placing specific work or operational detail into the plan, you might be spending too much time on planning. Eventually, you will get better at planning as long as you are willing to exert the appropriate amount of energy into this process.