Help! I Have Both Waterfall & Agile Projects in My Program
Categories:
Agile,
Best Practices,
Leadership,
PMI,
PMOs,
Program Management,
Project Delivery,
Scheduling
Categories: Agile, Best Practices, Leadership, PMI, PMOs, Program Management, Project Delivery, Scheduling
| By Kevin Korterud As both a project and program manager, I’m always keen to have projects and programs take the right first steps toward success. In the past, this would involve selecting the unified delivery approach used for all of the projects on a program. The idea was to impart consistency to the way projects were managed as well as produce common metrics to indicate progress. It’s not that easy anymore. Today’s programs have projects with agile, waterfall, supplier, corporate and sometimes regulatory-mandated delivery approaches. In addition, these approaches as well as the different arrangements made with suppliers (e.g., time and materials vs. fixed price with deliverables) have dramatically increased the level of complexity and diversity of delivery approaches within a program. So as a program manager, how do I keep all of these projects in sync no matter the delivery method? As a project manager, how can I execute my project in concert with the overall program in order to maximize the value that will be delivered, while avoiding schedule and cost overruns resulting from projects not operating in harmony? These are emerging challenges for which there are no single easy answers, of course. But I have found a handful of tips useful in getting a program’s projects to operate in a synchronized manner. I’ll share the first few in this post and the final ones in my next post, appearing later this week. 1. Remember: There’s No Such Thing as Agile or Waterfall Programs Given the mix of project delivery approaches, the program needs to properly segment work to manage the budget, resources and schedule regardless of the project delivery approach. In addition, the schedule alignment points, budget forecast process and deliverable linkages need to be identified between the various projects. Typically, I find that while there is effort to plan for these items at the project level, the upfront effort for this harmonization at the program level is underestimated or sometimes left out altogether—program managers think the project teams will figure this out themselves. This sets the program up for schedule and budget overruns as well as overall dilution of the program business case. Some ways for a program manager to harmonize projects on a program include:
2. Make the Correct Delivery Approach Choice Before a Project Begins The type of delivery approach for a project is determined by the type of work being performed and the end consumer of the project’s deliverable. For example, a project on a program that is slated to create a consumer portal would be a desirable candidate for an agile delivery method. Another project that involves heavy system integration that a consumer never sees would be a candidate for a waterfall approach. A project to pass data into a government system would likely have its delivery approach set by the governmental body. So before a project starts, program and project managers should agree on the optimal delivery approach that is the best fit for the project. Look for more advice in my next post on synchronizing a program’s projects, regardless of delivery method.
|
Don’t Shout the Loudest—Think Ahead
Categories:
Best Practices,
Communication,
Complexity,
Documentation,
Leadership,
Project Planning,
Risk Management,
Scheduling,
Stakeholder,
Strategy,
Teams,
Tools
Categories: Best Practices, Communication, Complexity, Documentation, Leadership, Project Planning, Risk Management, Scheduling, Stakeholder, Strategy, Teams, Tools
|
Have you been in situations where it seems that only shouting generates results? Or has your team been pressured to complete tasks that don’t appear to benefit your project? Maybe as the project manager, you have been in the middle of confusion and agitation that seem to undermine your project management abilities. Could it be that many of the scenarios you encounter have their roots in conflicting stakeholder requests and misunderstandings? Well, it’s possible to avoid these types of predicaments. Consider utilizing the following three tools that allow you to have better control of your project and your project team: 1) Communications Plan. Outline a plan with names, contact information, and details on when and what messages need to be delivered to and from you. This tool allows you to know the frequency of message exchanges and the media required for specific contacts. It also lets you know what level of detail the message should have, i.e., if it is going to a senior manager vs. a member of the supporting team. 2) Stakeholder Analysis. Prepare an analysis of your stakeholders to understand what their roles are and what area of your project is impacted by their involvement. This tool can help you with the department that has the biggest impact all the way down to the departments that have even a small effect. Additionally, this tool can show how those who are directly or indirectly connected to your project may have an influence that can be detrimental. 3) Project Plan. Develop a plan with the focus on your project objectives and what the project will entail. Organize the plan for what needs to be done and when. The tool should show ownership and timings that you can share with stakeholders to also make them aware of the potential influence of their requests. Sometimes, we get can get distracted when trying so hard to make sure our projects meet every need. There are many voices, conflicts, risks and events that affect the success of our project. Leaning on these tools may make your stakeholder management process smoother.
|
5 Things You Never Want To Hear On A Project
| Starting out as project managers, we begin to recognize the signals that point to project risks. Initially, these signals come in the form of status reports, work plans and delivery metrics. As we gain experience, we learn to sense additional risk signals that come from observation and dialog. And those signals originate from project managers themselves. These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team. In my experience, here are some of the signals that have pointed to a project headed down the wrong path: 1. "We'll start the project at the kickoff meeting." Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time. 2. "This project WILL finish on time and budget." This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs. 3. "The CEO is the sponsor for this project or program." Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project. 4. "We are four weeks behind schedule, but we'll make it up in the next phase." Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions. 5. "I feel green." A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story. For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said, "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project. While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them. What have you found to be good examples of signals that point to risks on projects? |
Finding the 'Flaw' in Projects
| The next time your boss asks you for a number, a deadline date or another fixed value, remember anything you say will be wrong. The reason is 'the flaw of averages.' Discussed in a book of the same name by Sam L. Savage, the flaw of averages basically explains why everything is behind schedule, beyond budget and below projection. For example, you're developing two software modules. Both are expected to take between eight and 12 weeks to complete. When both modules are finished, your organization can start a new process, which requires four additional staff. Your boss asks you for a completion date so the additional people can be brought 'on-board' and the new profitable line of business started. You say, "Eight to 12 weeks," and your boss replies, "Give me a date!" You estimate that a safe date would be 10 weeks, the average of eight and 12 weeks. Everyone is happy. But should they be? Let's look at the flaw of the average: Based on your projected date, your boss works out his profit forecast for the next quarter based on an estimated profit of US$1,000 per week. You take the first seven weeks developing the application, and the new team uses the application for the remaining five weeks. This sounds sensible, but the estimate of US$5,000 profit is the best that can be achieved. If you finish early, there is no upside. The new people will not be available. If you finish late, however, sales will be lost. The cost of the unproductive new staff will be an added expense until both modules are working. On average, the profits achieved are likely to be significantly less than US$5,000. Plus, you're more likely to be late than early. The probability of finishing each of the modules in 10 weeks or less is 50 percent. It's like tossing a coin - there is always a 50 percent chance of it landing on 'heads.' Since two modules need to be finished in 10 weeks or less, think of the options when you toss two coins: Tails + Tails Tails + Heads Heads + Tails Heads + Heads There is only a one in four chance of you achieving the 'average.' That 25 percent probability means there is a 75 percent probability of being late. Therefore, on average, you can expect to be late. All you did was assess a reasonable number based on your expected average time to complete each module. The problem is not your estimate, but the way it is being used. This is the flaw of average. The next time you are asked for a 'number,' use your skills in managing upward to build flexibility into the conversation. For example, offer your boss a safe date with an option for improvement. "We will definitely be finished in 12 weeks, and there is a possibility of finishing sooner." Point out the cost risks of being early and late. Keep the boss updated as you work through the project. Or, do some serious analysis. Offer your boss a range of dates with different levels of probability. You need tools for this, but you want a target date with an 80 percent probability of achieving. Effective stakeholder management needs more than simply complying with a request -- however reasonable it may appear on the surface. |
4 Metrics to Help Spot Trouble for Agile Teams
| In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips: Juggle Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time. Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions. Plan leak This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning. Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work). In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates. Execution leak Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less). Jelly This shows how much unplanned work was added during the iteration. In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints. What do you think? Have you used these metrics? What metrics do you use to help spot trouble? |
