Taking on Project Management Myths, Part 5
Categories:
Agile
Categories: Agile
| It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses. Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance. Truth: Comparing budgets to actuals is not only useless, it's misleading. To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement. Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000. You time-phase your budget US$1,000 in month one and US$1,000 in month two. At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing? If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class. If you said, "It depends on how many widgets you've made," go to the front of the class. Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them. A very simple example, I grant you, but it starkly supports my assertion. The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry. Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted. My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep. The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be. What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare. So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda. But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary. So what do you think? Myth or reality? Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice. |
Defining Your Project
| Project management may not be all about document management, but it's a necessary and important part of the job. And it all starts with the project definition documents created in the planning phase. As the name implies, these documents outline the details of a given project, such as business goals and requirements, scope, budget and project management plan. Project definition documents should include: Basic project data: Goals, objectives and any business issues to be resolved Project execution parameters: Definitions of project boundaries, key policies and procedures that are specific to the organization and that must be followed to integrate the project work and its result into the organization during and after the product delivery Required project management methodology: Governs how the project is planned, how each phase is executed and what's required to move from one phase to another And don't forget any other information that might be helpful to anyone who wants to know about the project. What's great about A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is that it offers project managers an idea of what should be included in the project management plan. Project managers can then create various project definition documents that best the the project at hand. What tips do you have for putting together project definition documents? Are there certain processes you always follow? |
Putting the PMBOK® Guide in a Cultural Context
Categories:
PMI
Categories: PMI
| A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is developed by hundreds of volunteers to represent generally accepted good practices in project management. But is this enough? There are already extensions to the PMBOK®Guide for the construction industry and government that expand the basic framework to meet the needs of these sectors. Is there a need for extensions to meet the needs of different cultures? The value of diversity and the challenges of managing culturally diverse teams was the focus of Tom Sullivan's feature article "Common Ground" in the October issue of PM Network®. My column in the November edition of PM Network, "Culture Shock," highlights some contractual issues that impacted a major mine development. As projects and teams become more global, managing appropriately within and across cultural boundaries is a key project management skill. Although there's no right or wrong in culture, different societies resolve challenges in different ways and use very different structures to communicate information within businesses and projects. As PMI moves toward the start of the next PMBOK® Guide update project, I would like to take the opportunity to discuss issues and challenges of managing projects in a cultural context. Do we need cultural extensions to the PMBOK® Guide or is there more value in retaining it as a core definition of good practices that apply worldwide? I've had my say in PM Network, now it's your turn to weigh in. Over to you! |
Taking on Project Management Myths, Part 4
Categories:
Risk Management
Categories: Risk Management
| Part four of my taking-on-the-myths series will challenge our statistically minded segments: the risk managers. Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted. Truth: Monte Carlo simulations are needlessly complex and shouldn't be used. Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust. But is it really? Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs. This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly. But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding. Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle. Truth: After the baseline is set, formal risk management is pretty useless. This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying? Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success. |
Setting the Real Schedule
| Effectively planning a project timeline starts with gathering the appropriate inputs to develop schedule process. And spending the time to carefully plan the activities, sequence them, define durations by gathering this data from performing resources, build resource calendars and get estimates is critical to the project. It ensures a great start, good data and estimates that are better than just an educated guess. But, I often find many holes in the scheduling exercise. You have to deal with a lot of details about the activities being planned, the maintenance windows, resource availability (or unavailability), the timing and sequencing of activities, the amount of detail we have vs. the amount we actually need, etc. I find it helpful to map out key activities on a wall, with the critical path being set and clear. Then I break the activities down and put the similar chunks of information together. You don't always get a complete picture of the schedule--it's a progressive process. And you sometimes you miss some things when you don't visualize all the steps that you have to go through. But it fleshes out the dependencies and the risks. Of course a lot depends on the project itself, how much information is already available and how much knowledge the person who does scheduling has about the technical side of the project itself. Many project managers tend to bypass this process or minimize it and leave it to the day-to-day "figuring out" process, rather than planning the scheduling sessions with the team. That reduces the quality of the overall plan and forces the project to go through more changes than it has to. Controlling the project schedule is a process that is done a lot easier when the upfront work is done. Coupled with accurate reporting on project status, the schedule can be easily adjusted and kept up to date and relevant, without constantly re-baselining the schedule. |
