Innovative Project Management

There has been a concentrated focus on "innovative” project management of late. This focus is undoubtedly due to the chilling effect the financial environment has had on projects. There are two directions project managers are being asked to demonstrate innovation: "Greening” projects andsaving money. The public is demanding projects that reduce our carbon footprint, both in the area of energy and construction, while business is demanding that projects reduce their budgets or they are canceling them altogether. Project managers are being asked to "think outside the box” in order to shape their projects’ goals, objectives, and budgets to suit their sponsors’ expectations.

I don’t know enough about the technology to offer advice on how to make project’s green or reduce a project’s carbon footprint so this article will focus on using innovation to reduce the cost of projects.

There is some temptation to infer that the drive for innovation means that we should throw away our existing best practices and replace them with a new "innovative” set of practices that will magically reduce our project’s costs without impairing their goals and objectives. Not so, it is more important than ever to maintain our toolkit of project management best practices. I like to compare the collection of best practices we use to the tools a cabinet maker uses. Cabinet makers don’t replace their tools when a change in public taste or the economy make kitchen cabinets a hot seller and china cabinets can’t be given away. Their tool sets remain the same, but the way they use those tools and the resources they use will change. A good cabinet maker must be skillful in the use of all the tools in their toolkit and the first time the skilled cabinet maker makes a kitchen cabinet, that cabinet will reflect the cabinet maker’s skill and experience. The smooth surfaces, routed edges, perfect alignment, and tight fitting joints will all be what we expect from a skilled craftsman.

Project managers need to become skilled in the use of their tools. Skill and experience in the use of project management best practices will enable the project manager to deliver any project on time, on budget, on scope, and to the quality standards required. There is no better way that I know of for project managers to begin this journey than by passing the PMP certification exam administered by PMI. There are many excellent PMP coursesand PMP Exam preparation training products available to prepare you to pass the exam so there is no excuse for not taking this first step. Project managers who are proficient with the best practices in their project management toolkits will be ready to meet the challenges presented by the demand for innovation. I offer the following tips to help you with ways of delivering your project for a smaller budget without sacrificing any goals or objectives that are critical to your organization.

Prioritize Projects

Each project should have a business case which states the benefits the project will provide and the forecast cost of the project. Your job in the area of creating or maintaining the business case doesn’t change with the need to be innovative, but you should change the way in which you approach that task.

It is in your best interest to identify projects which are a low priority for your organization based on their business cases. Elimination of low priority projects, even your own, may preserve your organization and your job. Your project should be described by a standard business case if you work out of a Project Management Office (PMO), or Project Management Center (PMC) and your task is to simply portray the costs and benefits as accurately as possible. If not, you can help by working with your fellow project managers to settle on a standard business case template. Take the lead in this area and either choose an existing template to use, or propose your own. Propose to the project management team that this template be used to capture the business case for all projects.

The benefits stated in the business case should support organizational goals and objectives. State the goal or objective each project supports in the business case. Be honest in your appraisal of the alignment between the benefits stated in the business case and the goal or objective they support. A project which provides an automated system that will reduce operational costs by 10% does not align well with an organizational objective of a 10% reduction in IT costs. A project which implements software tools to automate database maintenance which will reduce Database Administrative effort by 50% would. Stating the benefit of the first project as a reduction in operational costs of 10%, while stating the objective it supports as the reduction of IT costs by 10% will be enough information to allow the business to make their decision.

Prioritize Requirements

Managing requirements for your project will require you to use the processes and procedures you learned from your PMP course or PMP exam preparation training. These best practices won’t change because you’re looking to trim requirements from your project, but there are some new wrinkles you will need to add in order to put your project on a diet. Managing requirements starts with choosing the right group of stakeholders to solicit and excluding those stakeholders who are not directly involved in building or using the system. The need to exclude this latter group is heightened when you are attempting to organize a "lean” project. It also becomes more important tocapture the requirements in clear concise language; the acid test for your requirements should be "Can this requirement be tested?” If the answer to that question is no, the requirement must be re-stated, or the tools available for testing must be upgraded. It is also important to uniquely identify the business requirements and to carry that identification forward through design, build, and test so that each feature or function can be traced back to its parent requirement. There will be more pressure on you to deliver each and every requirement in the approved set when that set has to be kept as compact as possible.

The budget hammer may fall on your project at the outset, or at some point before the end. The closer to the beginning this happens the better equipped you will be to re-act, but prioritizing the requirements during the planning phase is the best way to prepare for a budget reduction. The project’s goals and objectives should be clearly stated based on the benefits described in the business case. These should be stated in the Project Charter and each requirement should be rubbed up against them to determine alignment with a charter goal or objective. A requirement that directly aligns with a project objective that enables 8% of the 10% cost savings forecast would obviously be a higher priority than one that indirectly enables 2% of those same cost savings.

Requirements that are "extra baggage” and don’t support any charter goals or objectives should be jettisoned when times are tight. They don’t have to be discarded; they can be shelved for inclusion in some future project. If the requirement is the hobby horse of an influential stakeholder, include it in the Business Requirements Document, but set its priority to the lowest possible score. Not every requirement will directly support a charter goal or objective. Those that indirectly support that goal or objective should inherit the priority of the parent requirement. Each requirement in a set that composes a high priority feature or function should be assigned the same high priority. Some requirements that don’t support any of the charter goals or objectives may still be a high priority. Take the log-in screen as an example. The charter may have no stated goals or objectives around security beyond providing a software tool to configuration engineers but the log-in screen will be critical to application so is a "core” requirement. Make the scoring exercise as scientific as possible to avoid political battles. You might start by prioritizing the charter goals and objectives then prioritize the requirements based on their alignment with these.

Choose the Right SDLC

The SDLC you use to produce your software will influence the cost of producing the software system. Iterative methods will tend to require more overhead because processes are repeated for each iteration rather than just once. Iterative processes are used to discover flaws in the technology being used (e.g. the development platform or tools), or the concept being developed, or the project approach. Mistakes can be detected early in the development phase and corrected for future iterations. The Waterfall method is used because the technology and tools used have been proven by the organization and the system being developed does not contain any new features or functions whose feasibility must be proven. The project manager must analyze the needs of their individual project to determine which SDLC best meets those criteria. The need to use the tried and true criteria and procedures you have become familiar with does not diminish because you must consider new ways to deliver the project on a smaller budget; it just means that bringing the project in at or below budget becomes a higher priority.

The need for a smaller budget is closely related to the need for speed in the world of software development (the same principal probably applies to most labor intensive projects, but software development is the area I’m familiar with). This need will cause you to think outside the box when it comes to determining which SDLC best fits your project needs. Methods which are great at eliminating the risks associated with using new technology or tools won’t necessarily deliver the cheapest project. Your organization may be looking to switch to a different development platform, development tools, or testing tools to save money in the long run, but can it bear the increased cost to your project? There will be a trade off here: increased cost to pilot the new technology vs. reduced costs in the long run. Make sure your organization is aware of the trade off and either delay the introduction of the new technology to reduce your project costs, or acknowledge and accept the increased cost to your project.

There are ways in which you can offer a reduction in project costs by thinking outside the box when deciding on an appropriate SDLC. There is no rule that says you can’t mix and match the features of the various SDLCs, in other words invent your own SDLC. Let’s take a project that delivers a web site upgrade using a development platform new to the organization. On the surface, it might seem that an iterative method which allows the team to learn about the platform as they go would be the logical choice, but maybe you don’t need all those iterations. Try a pilot project, or prototype, combined with the Waterfall method instead. Take care to deliver a working system at the end of the pilot or prototype build that proves the entire new platform and can be built on to produce the entire system. This particular combination may not be the answer to your problem, but treating the various methods as an assembly of parts from which you can pick and choose may allow you to come up with a custom method that is ideally suited to your project’s needs.

Look for Alternatives to Costly Features

Business requirements should be expressed without regard to how the requirement will be satisfied by the software system being built. This leaves the design experts (Business Analysts and Systems Analysts) free to design the software as they see fit. A design that meets the requirements is not necessarily the most efficient design because it has been crafted by an experienced Business or Systems Analyst. These folks may be reading nuances into the requirement which aren’t there, or at least are not there explicitly. A review of a cost feature/function design may unearth an alternative approach which delivers the required functionality (the requirement explicitly described in the Business Requirements Document) with less effort.

Begin your dieting exercise by making the objective clear to the team. You should have facts and figures to hand when communicating this message. Facts such as total project budget, budget for design and build, total hours of effort funded by the budget, etc. are all valuable pieces of information when trying to impress the importance of frugality on the team. Design reviews are another aid to effort reduction. Make certain that your moderator and core team of SMEs fully understand the importance of seeking less costly alternatives and ensure that goal is one of the objectives of each design review.

Communication is essential to this exercise and thecommunication tools that helped you focus teams on project objectives in the past will serve you well here. Use techniques that have been successful in the past. Here’s another suggestion. Implement an awards program for the team member who proposes the alternative that saves the most effort for the week or month. The award doesn’t have to be a large one in monetary terms, but should reflect the importance that the management team places on savings.

Test Efficiently

Efficient testing in this case means avoiding duplication of effort. I have advocated making test cases written by the QA group available to the development group so that the code going into QA test is as clean as possible. I still maintain that this approach will save re-work over the long haul. What I mean by efficiency here is that you make the best use of resources available to you. One way of maximizing resource utilization is by combining user training and User Acceptance Testing. Make access to training contingent upon participation in User Acceptance Testing. Another is to hand off some of the QA test cases to the UAT team.

As participants in UAT are usually free to the project, it is desirable to burden them with as much testing as possible. These resources are free to you because they are not project resources so you must offer some incentive to your potential testers in order to motivate them. The ability to allow them to perform their work on the test platform is one such incentive. Enabling this will require you to port the data to the production platform as part of the cutover process, but taking this step will allow you to test the system under production like conditions. Check your QA test plan and make sure that as many test cases as possible are moved from that plan to the UAT test plan using production data.

Conclusions

Opportunities for project managers to conserve the resources of their organizations abound. To seize these opportunities the project manager must have two attributes: they must be willing to innovate and they must be experienced enough to differentiate between an innovation that is likely to succeed and one that is likely to fail. The methods that have delivered overly expensive projects in the past will still work today. They will still be successful at delivering overly expensive projects. To reduce the cost of projects the organization, from the CEO down, must be prepared to take intelligent risks on innovations their experienced project managers propose. Project managers must not give in to the temptation to abandon the best practices that made them successful; keep these tools and learn to use them to produce a different, less costly, result.