Project Management Methodologies and Tools: Is Your Process or Tool as Simple as it Can Be?

This is a guest post by Brian Kennemer, Senior Enterprise Project Management Consultant at Microsoft.

Obviously we are all making adjustments because of the changes in our economy. It has caused us to reexamine what we work on and how we work on it. For many of us, it has meant having fewer team members but the same expectations for what we need to accomplish. How we spend our time is always important, but is even more important now. There has never been a better time for reexamination of our processes and our tools.

A methodology should require you to document or track only as much as is absolutely required for the PM, the team and management to make decisions and accomplish the real work (or if the document or action is required by your customer or by regulation.) Often though, our methodologies call for the generation of reports and documents that are never read or do not actually add value to the project. The question I always ask about such things is “What decision would be made impossible or more difficult if we did NOT do this step, write this report or generate this methodology deliverable?” Software development is an area where one can find methodologies that are on the extremes, with some calling for huge outpourings of deliverables and others calling for next to nothing with regard to requirements and documentation deliverables. Somewhere in between lies what is best for most of us. Do you really need every deliverable that your projects are creating? Would there be any ill effects if some of them were not created? Run your deliverables through a few tests to see what the impact would be if they were not produced or if they were produced in an abbreviated form. How much time would that same per project where a project manager or team member could be adding real value? Be ruthless. Sure you have “always done it” but that does not mean you always have to. Answer this question for all your deliverables: “When was the last time someone accessed this deliverable for the last year worth of projects in your organization?” If nobody has accessed it for that number of projects it should be slated for cutting from the methodology.

This same idea works for the configuration of project management software systems (well really ANY software system actually.) I use this principle for every design decision I make when I’m working with clients on their Microsoft Project Server deployments. Before I will add a custom field I want to know what views it will be in and how that field being there will support a key business decision or enable project work to be accomplished. Before I create a view I want to know who specifically will use it and what decisions they are making while viewing it and how NOT having it will impact the project and the process.

A view in Project Server Web Access or a SQL Reporting Services report is in the system for a specific reason. It is designed to support a specific business decision. If an executive needs to be able to see the start and finish dates, the total effort and total cost of projects broken down by which organization is paying for the project and which strategic goal the project supports then there is a view for that. For that view you need the project name, the start and finish dates, work effort and cost totals. All project management systems produce these fields as a matter of course. Also needed though are fields that align the projects to an organization and to a strategic goal. So in this case we need to add two custom fields. If this were the only view required then we would only need two custom fields. We would not need a field that tracked what software system the project was modifying or what geographic region the project team is in. Even if you currently capture that information and 20 more data points you don’t need them if they are not going to be in a view or report that is going to help someone make a real decision. Again, be ruthless. If the justification is “It would be interesting to know” then your next question should be “Why would it be interesting? What is going to be done with the knowledge that such a field would provide? To whom would it be interesting and useful?” The answers to these questions will help you know if the field\view\report is actually needed.

“Doing more with less” is not just a cliché, it is an all too real fact of life that requires all of us to figure out where time and effort can be saved. Smoothing out your methodology and your project management system data collection scheme may not seem earth shaking in its impact but it can make a difference in the time spent by your project managers and team members. They are the ones that are actually feeling the impact of the current situation. Taking unnecessary items off their plates frees them to do the real work you are paying them to do.

Action Items:

1. Look at your project management system and see what it is capturing about your projects and tasks. Ruthlessly question the value they add and analyze the time spent creating or maintaining them. Kill the items that fail to provide the required value for the money spent.
2. Take the same ruthless look at the data your project management system is capturing. Do all those fields show up in reports or views that are actually used to make decisions? If not then think about removing them.