There is nearly an unlimited amount of discussion on the web about projects, project success factors, project management methods, including software development methods and paradigms, and of course project management tools that support them. All of these are solutions looking for a problem to solve. And there are lots of problems to solve, so these solutions can find an easy home.
Along with these come books, articles, paper, conferences, blogs, twitter feeds, and Face Book pages. All trying - we'll assume with good intent - to improve the probability of success of projects.
So here's the big question, and by big I mean the cost of the project and the value it produces. How can we determine if we are prepared for this success? There are several competency assessments for project managers. From essentially commercial ones, to work done in NASA and DoD. But the readiness for success for project at the data and process level is not usually found in the literature.
Here's one approach that has served me well. There are five process areas for managing projects in the domains I work. These include hardware development, things that fly, swim, and drive. Software development, things that process other peoples money, control the behaviour things that fly, swim, or drive.
- Organizing - Define the work, determine who is going to do the work, and document these in some manner for others to see. The result is a work breakdown structure (WBS) and an organizational breakdown structure (OBS), which describes the relationships among the participants in the project —the engineers, managers, and supervisors—and the roles they are playing on the project. The WBS can range from a list of cards on the wall to a formal MIL-STD-881C WBS. No matter the media we need to know in some way what we are building, otherwise we'll never recognize when we are done other than we ran out of time and money. The OBS is the “roster” of participants on the project and their individual capabilities. The intersection of the WBS and OBS defines the person accountable for delivering project outcomes. This can be a single individual or several individuals, accountable to each other and to the project manager.
- Planning and Budgeting - Plan the order of the deliverables for the project, schedule the work needed to produce those deliverables, and develop the budget for the work. These three items are the least amount of information needed to manage the project. Anything less lowers the probability of project success. These can be represented in a formal DI-MGMT-81861 Integrated Master Schedule, or again those sticky notes on the wall. But most non-trival projects have a needed order of development. Figure that out before starting with the first pieces.
- Accounting - how are we keeping track of the money we are spending to produce the expected value? Capture the actual costs of doing the planned work and compare these costs to the budget for this work. This information and the measures of physical percent complete are used to assess the performance of the project and identify corrective actions needed to keep on schedule, on budget, and in technical compliance with the planned outcomes that provide the needed capabilities for the customer, while the technical and operational requirements are being implemented. The notion of not budgeting that is intentionally not knowing what the cost is seems a bit silly when you ae spending other peoples money. Some way, some where, some one needs to know how much this project will cost in the end. With knowing the cost all the fancy searching around for value is for naught. And that noble Return on Investment gets a divide by zero error, since ROI=(gain-cost)/cost. Don't know what something costs, you can't know the ROI. Don't know the ROI, you can't know the value. This is simple arithmetic - as Billy Clinton says.
- Analysis and Management - are we performing to our plan? We do have a plan right? If so, are we making the planned progress? Are we close enough to the plan to show up more or less on schedule and more or less on budget. With the project plan and the actual work on the project, we can now assess cost and schedule performance and technical outcomes. This analysis allows us to determine variances, so that we can take corrective action to keep the project going as planned. If we don't have a plan, measuring progress from past performance is simply a waste ot time. It's an open loop control system. No target for the performance of our work. Just writing the numbers after the fact. Maybe using those numbers for the next project or the next iteration, but never knowing if we could have better or worse.
- Revisions - when we make changes to anything, do we keep track of these so we can remember what happened? When there are changes to cost, schedule, capabilities, and technical performance requirements, we must record these changes so we don’t forget what changes we made and why we made them.
Now for the Domain and Context Connections
For projects that are more traditional in nature - construction, metal bending, system integration, capabilities and requirements driven, budget based, expected delivery dates, with multiple stakeholders - it should be obvious how to connect the process above to the activities of the project. I know it's not obvious, it should be. If it was we'd have much better success rates on the projects.
For other projects, where there are not as clear and concise capabilities being stated. Or agile projects, where the customer is paying the team to discover what capabilities and the requirements that implement those capabilities, these processes still have merit.
In the end though, these processes need to be found in ALL projects or there simply isn't enough information to adequately assess where the project is going, when it is going to arrive at done, and how you're going to get there from here. No matter how often it is tried to avoid answering these questions, they just won't go away for all the right reasons?
- What are we building?
- How can we recognize that what we are building is what the customer wants us to build?
- How much will it cost when we are done?
- When will we be done?
- What are the impediments to reaching done is some timely manner?
- What are we going to do about these impediments to make them go away or reduce them enough so we don't care?
- How can we respond to emerging situations, while still assuring the customer we know enough about the cost and schedule, so they can have enough cash on hand to complete this project?
