Sections Syndication |
Home : IT Project Management : Obtaining Management Approval
Obtaining Management ApprovalObtaining Management ApprovalOnce the WBS has been initially created, it must pass through management for a final sign-off. In some instances, such as when the project manager and the project team are consultants or vendors integrating the technology into an existing enterprise, the project manager probably won’t have to pass every work unit within the WBS through management for approval. Presenting to the Project SponsorThe project sponsor, the advocate of the project, will be the first stop on the road to approval of the WBS. The project manager must be prepared to explain any phase of the WBS to the project sponsor. If the project manager has fully researched and skillfully planned the WBS around business cycles and the team members’ schedules, there should be few revisions to the schedule. However, if the project manager has failed to work with the team, consider business cycles, or take into account other implementations within the company, the project sponsor can (and should) work with the project manager to correct these timings. You can imagine the frustration that could ensue if the WBS has to be re-created because of poor planning and an inadequate understanding of other activities within the IT realm of an organization. Not to mention that failure in creating the WBS does nothing to gain the confidence of your project sponsor and the project team. Presenting to Key StakeholdersOnce the project sponsor has approved the WBS, the project manager should present the WBS to the key project stakeholders. Depending on your organization, this may be the customer of the project, another department within your company, or management. As always, tailor the presentation for the audience you are speaking to. The WBS presentation does not need to go into great detail for each task represented within each phase. To begin the presentation of the WBS, start at the deliverables of the project. By again reminding the stakeholders what the project will produce, you’ll be reinforcing their decision to move the project forward. The whole point of presenting the WBS to management is to confirm that your project includes all of the deliverables they’ve requested for the project. Again, this will serve as the scope baseline for the project, therefore, everyone’s agreement is essential. Once you’ve established the deliverables, reveal the phases required to reach them. It would be most effective to show a timeline, perhaps created in PowerPoint, of the start and the finish dates of the project. As each phase is revealed, superimpose an arrow over the timeline to show where each phase will put you in relation to the project completion. This will allow your audience to visualize how your plan has been well conceived and how each phase will produce a deliverable, moving your team, and the company, toward the end result of the project. Figure 5-6 features an example timeline. Within each phase, you may wish to show a few of the highlights to convey the activity that is required. It is not, however, necessary to illustrate every task required to complete each phase unless the stakeholders explicitly ask for it. You should be prepared to discuss each phase in detail, and it would serve you well to have an alternate presentation that does include each task of each phase of the project. Generally, stakeholders do not want to know about each task associated with installing a cable, replacing a workstation, or upgrading a server. You should, however, always share with management any phase of the project that may require any downtime of IT components, even if it is over a weekend. Part of the WBS should address these downtimes, if they exist, so that the stakeholders are aware of the impact. Always take into consideration, through audits and logging, the type of activity that occurs over weekends or at nights due to remote users, international users, and users who work late and long hours. Don’t assume anything. If management does not approve the WBS, the project manager should immediately address any areas of concern. In some instances, management may approve on the condition of a few revisions. In other circumstances, management may delay your approval in order to study the WBS in detail. Plan your management approval meetings in accordance with what’s the norm in your environment. If management always delays decisions to begin projects, don’t let their delay infringe on the implementation. Plan the WBS approval meeting with ample time for management to review and revise your plan. If your WBS needs to be approved immediately, stress to the stakeholders that the schedule must be implemented within x number of days. If there are no concerns with the first phase of the schedule, then perhaps at least that part of the plan can begin while management reviews the later details.
Interview with Geoff Choo Name: Geoff Choo Geoff Choo is a project manager for Invisible Site, an Italian interactive media agency, and a freelance business and technology writer. In his spare time, he helps produce Netstatistica Report (www.netstatistica.com), a free monthly newsletter with Internet economy facts and stats at a glance. He contributes regularly to Gantthead.com and is a contributing editor for Europemedia.net. He has previously worked as a project manager and web developer for IconMedialab. You can get in touch with Geoff at geoff@netstatistica.com. Q: What is the best thing about IT project management? A: I have a holistic vision of web development, which means that I've done everything from art direction to HTML design to web programming to search engine optimization. But that also means that I'm a jack-of-all-trades and a master of none. Web project management lets me use my wide range of experience to facilitate communication between manager, programmers, and designers, who don't often see eye-to-eye. Q: When you begin to create a WBS, what do you do first? A: My projects are based on a lifecycle of major phases, like definition, design, build, test, and launch. I begin the WBS process by identifying and defining all the deliverables that will be generated under each project phase. Deliverables should be general descriptions of functionality to be completed during the project. Then I decompose all the deliverables into actual work requirements. Q: What is the most important element in a WBS? A: Remember that while you might know all the high-level deliverables and activities, you might not know all the lower-level activities that will complete your WBS. If you don't know how to break down a higher-level activity, don't guess your way through and don't ignore that entry; go out and ask the people who will be responsible for the activity to tell you what the components of that activity are. Q: Do you use a software package to create your WBS? A: I personally use a flowchart program called Visio, because it's a really powerful program. However, when I have to collaborate with people who do not have Visio, I use the design and flow-charting tools that come with Microsoft PowerPoint to create my charts. It's not as powerful and intuitive as Visio, but at least the program is more widely diffused. Q: When creating a WBS, do you work in phases or do you attack the whole project? A: I work the WBS in iterative cycles, since it's exceedingly difficult to map out all your activities in one fell swoop. Start with your main deliverables in the first cycle, and then decompose down to the high-level activities, for example, define requirements. Validate that you have broken down every deliverable into all the high-level activities required to complete that deliverable. Then decompose every activity into more granular activities in iterative cycles. At the end of every cycle, remember to validate that you've included every subactivity required to complete that higher-level activity. Q: How do you predict how long each task may take? A: From personal experience, or by using historical data from our time-tracking tools, or by simply asking the team member who will be responsible for completing that task. Q: What methods do you use to assign tasks to team members? A: My company built a project-tracking tool in Outlook using Microsoft Team Folders. I use the task assignment tool in Outlook to assign and track status on tasks. Q: How important is it for a project to have a WBS? A: Running a project without a WBS is like going to a strange land without a roadmap. A WBS provides you with a concise roadmap for reaching your destination. If you know which steps you have to take and which path you have to follow, it's going to be easier to get to where you want to go. Q: How granular should a project manager get when creating the WBS? A: Decompose the WBS as deeply as you need. There are no hard and fast rules to how granular a WBS should get. It all depends on the complexity of the project, the level of risk, how skilled your team is, and how much detail you need to maintain the necessary level of control. If you're working with a skilled team, you could probably get away with a shallow WBS. If you need more control on a complex project, the WBS should be decomposed as deeply as you can go. Generally, the deeper the WBS gets, the smaller (and shorter) the activities become. But don't go too deep. You should decompose the WBS as deeply as you need, but there is a logical limit to how deep you should go and how small (or large) an activity should be. A general guideline that I like to follow is that each lowest-level activity in the WBS should be assigned to a single individual, and that individual should be able to complete the activity between one to ten working days. Anything smaller than one day and you'll end up with a 100-level deep WBS with a huge list of five-minutes tasks. Anything bigger than ten days and you might not have enough level of detail to effectively control the status of that activity. Q: When should a project manager map out each step of an activity for a team versus identifying goals and allowing the team to create the solution? A: The WBS is at its core a hierarchy of deliverables or tangible outcomes. Each deliverable or outcome will have a set of related activities, and each lowest-level activity will have one individual responsible for it. It is not a to-do list of every possible thing we can think of that needs to be done in the project. Rather it lists the assignments we will hold members of the project team accountable for delivering. Whether you're working with an inexperienced team or a veteran team who can do things in their sleep, the important thing to keep in mind is that you must have enough granular detail to let you track status and progress on your projects. It's not just a matter of mapping out things for an inexperienced team or identifying the high-level goals for a veteran team and then letting them fill in the blanks. Q: When creating the WBS, how much involvement is required from the project team? A: I don't generally micromanage my team members and tell them all the things they have to do. I give them the high-level objectives and results I want from them, give them the tools to do it, agree on a metric to track progress, and then leave them to their own devices. This means that while I define the deliverables and high-level activities, the team members will fill in the blanks with the lower-level activities. I work with them to write down the lowest-level activities that I will use to track their progress. Q: What method can a project manager use to confirm that he's not missed a step of the project? A: Create the WBS in iterative cycles and constantly reevaluate the hierarchy of deliverables, activities, and subactivities. Always ask yourself and your team members, “If I had all these deliverables, would I achieve the planned objectives for the project? If I do all these activities, will I complete that deliverable? If I do all these subactivities, will I complete that activity?” If the answer is no, retrace your steps and fill in the missing step(s). Q: What does a project manager do if he realizes a component has been left out of the WBS and adding it will throw the WBS off schedule? A: Do what you would do if you were behind on a project:
Q: What advice can you offer to aspiring project managers in regard to creating a WBS? A: A WBS is like the outline your teacher always made you do before writing your report in grade school. You know what you have to do, but your head is swimming with a huge list of ideas and things to do. It's hard to begin doing something if you don't know where to start. Writers call this the dreaded blank page syndrome. Staring at a blank page doesn't usually make the words flow out; neither will sitting at a desk trying to figure out how and where to start building your project. Like an outline, a WBS helps you organize all your thoughts in a structured way, giving you something to start with and a list of steps to help you write your report or deliver a project. Start with the high-level outcomes that you have to achieve, for example, “create a user interface.” Then think about what things you have to do to complete that deliverable, for example, “find out what users want, create a user interface prototype, and test the user interface for usability.” Next break down those activities into more granular subactivities, such as “interview users and capture business processes.” Then go deeper and deeper until you have reached the desired level of detail.
1276
times read
|
||||
|
Did you enjoy this article?
(total 0 votes)
|
|||
Comments (0 posted) Please Comment On This Article
