Now-Focused Project Management

I would like to argue that there are really only 3 phases for project data. Two of them you are never in but always working on and one that you can never escape.

These 3 phases are Past, Present and Future.

I don’t mean to discard the idea of project phases such as Initiation, Planning, Execution, Control and Closing which are important framing elements for deciding who the key stakeholders are and what type of work is most important. What I’m trying to highlight is the 3 types of project data that come into existence during the process of running a project.

Past (Documentation and Commenting)

For any long-running project it’s important to be constantly working on documentation and ensuring that components being built are explained in a way that assists with new team members joining the work. It can be very easy to allow documentation to become an afterthought or wind up being ignored entirely. However – when documentation is done well it reduces the amount of time a developer needs to figure out the best way to add a new piece of functionality or plan for safely replacing a buggy module.

Present (Development and Testing)

The inescapable fact is that if a project isn’t making progress and that progress isn’t being verified as working then a project will never be complete – or (in the case of testing) will likely not function as expected when complete. Development can’t be let slip and testing shouldn’t be left as the last stage of a project. Wherever possible – every component of a large system should be tested as working in a controlled test environment (Unit Testing) and then tested as part of that larger system (Session Testing). For more information on testing – I suggest you read my article on Unit and Session Testing.

Future (Planning and Scope Verification)

In order to ensure that the right work is done in the right amount of time it’s important to have a plan which covers all the necessary components and the order in which they should be built. This involves creation of timelines and getting approval for those timelines from the key stakeholders. In order to get that approval the functionality which should be expected to work needs to be explained in a way that matches the requirements laid out in the governing project documentation (Statement of Work or Project Charter).

Conclusion

Ironically (given the labels of past, present and future) these tasks aren’t supposed to be done or left off until later. They all need to be done on a regular basis because if there’s no plan – there can be no development, if work is untested it can’t be documented, if work is undocumented you can’t plan for knowledge transition. If work is undocumented it can’t be verified against the scope.  Each one of the stages always needs to be done Now.