How Do You Define a Successful Project Management Career?
Categories:
Career Development
Categories: Career Development
| The criteria for what constitutes a successful project are pretty clear: full scope delivered on time and within budget. Consider how a "failed" project is characterized: Press reports of conspicuous project failures declare "the project was several years late." Or, "the project overspent by so many millions of dollars." But what does it mean to say that a project was late? Late with respect to what, some arbitrary date by which all such projects are supposed to be completed? And what does it mean to say that a project overspent? Overspent with respect to what? Some arbitrary amount that all such projects are supposed to spend? The fact is that both of these values -- project completion dates and the budget -- are not arbitrary in the least. These values are determined by the same person who is responsible to not exceed them: the project manager. Let's look at that. The project manager determines the project completion date and the budget. The project manager then manages the project so as to not exceed those values. Why, then, should a project ever be late or over budget? Think about it. We have it made! We get to say when and how much -- we simply have to meet those commitments. Our destiny is in our own hands. How can we fail? And yet ... we fail. I can hear the rebuttal now: "The schedule and budget were imposed by management, or the client or the sponsor." No they were not. You were given "targets." If you accept those "targets" as your budget and schedule commitments, you are setting yourself up for failure. As the project manager, you are responsible for determining the schedule and the budget. If you cannot bring them both in line with targets, the sooner you say so, the better. Success also means not failing. Quickly killing a project that will never meet targets is a good way to avoid failure. Alternatively, you can negotiate changes in targets for scope, schedule and budget so that it's possible to succeed. Regardless of your personal criteria for a successful career, success as a project manager implies success in managing projects -- and that means meeting commitments that you make. How do you define a successful project management career? |
A New Take on Standup Meetings
Categories:
Agile
Categories: Agile
| Short daily meetings are a cornerstone of agile project management. Team members usually address three questions: 1. What did they do yesterday? 2. What will they do today? 3. What roadblocks stand in their way? Some teams use an alternate format with a quicker flow. Looking at a task board, an appropriate team member says how many hours are left on each task. Once a task is complete, it's moved to the next state (test or done). If the team has capacity to take on more tasks, another one is pulled from the queue. At the end of the meeting, the team can see if someone needs work, can help another person or determine if there are any hindrances. This meeting format emphasizes little wins as tasks are moved from state to state. People get some positive feedback and congratulate each other -- which is important to the long-term functionality of the team. This type of meeting also keeps people from discussing work not related to the teams' tasks. It still allows space to discuss impediments and team utilization -- but only if necessary. Teams using this approach can complete their daily 15-minute standup meeting in 10 minutes. More importantly, there's a feel of energy and drive in such meetings. The three-question format is tried and true. If you find your meetings feel sluggish, give this format a try. You may find it turbo-charges your meetings. Which approach do you prefer? |
Managing Projects and Teams with Velocity
Categories:
Teams
Categories: Teams
| Velocity measures the rate of motion. In the context of projects, velocity is about teams accomplishing work faster, with less resources, better quality and greater satisfaction. As project teams get used to each other and adjust to the organization's processes, culture and communication methodology, team members' potential for contribution increases. As team engagement increases and members align themselves toward the goals and objectives of the project, overall performance increases. Velocity is achieved when team interactions are completely in sync with the project goals, the rationality behind the target dates and the planning it takes to meet those dates. In a project environment conducive to velocity: • There's a clear direction, everyone's roles are clarified and there's flexibility for team members to contribute in other parts as appropriate. • Members manage their own time, guided by their mandates or objectives. • Teams choose their own method of communication. It could be acquired from other similar projects or specifically designed for the given team. • Team interactions -- phone calls, meetings, workshops, etc.-- are managed as the needs arise, rather than "boxing" teams into preset parameters. On a project with velocity, the force behind the team executing the work gets to be so powerful that it's not the project manager who ends up giving the power to the team. The team itself generates that power and project execution moves with subsequent velocity. Are you managing with velocity? |
Project Management: An Organizational Competency
Categories:
Education
Categories: Education
| Competency-based management is a tactic that some organizations are using to recruit, hire, train, develop and manage employees. Competencies are sorted out in three categories: Organizational competencies combine the skills, information, performance measures and the corporate culture that an organization uses to achieve its mission. All employees must demonstrate these proficiencies. Job role competencies include the abilities needed to perform a specific role in the organization. A field supervisor, for example, must have similar skills to supervisors in accounting, customer care or sales. Although they are in different department functions, they must exhibit a common set of supervising skills. Position competencies are specific to the position you perform in your organization. An account manager, for example, must demonstrate capabilities that include proficiency in sales. An IT support engineer, for example, must be a master supporting the core systems an organization uses. It's common for organizations to think project management is a skill at the position level and that it is just for project managers. The reality is that project management is an organizational competency. If organizational strategy drives strategic changes and those changes are executed as projects, project management must be an organizational capability rather than a job skill. If project management is an organizational competency, it's required to define a training program within the organization to develop everyone's project management knowledge and abilities. I suggest starting with an awareness meeting for all employees. Once that's completed, host specific teaching sessions for executives who will support projects and then for people who participate in projects. Both must deliver non-technical project management knowledge. What do you think? Is project management an organizational competency? |
When Is Program Management the Right Choice?
Categories:
Program Management
Categories: Program Management
| Project managers often ask me: When is a program needed? Under what circumstances is program management appropriate? What's the difference between running multiple projects at the same time and running a program? In terms of delivering a benefit or generating a synergistic outcome, program management can help. This is especially true when you're managing interdependent projects. Say you're running four projects at the same time: a hardware development project, a 3-D character animation project, an exterior design project and a controller project for a game console. You can indeed manage these four projects separately with shared resources and technologies. But if two of the projects come from the same client, you should have a program. Or if your company plans to own the game console -- which requires you to produce a product by integrating the deliverables of each individual project -- you need a program. Take Nintendo's Wii. Development of the console definitely calls for the centralized, coordinated management of a program, or at least, a program-like logic to run it. Making the Wii requires coordinating the component supply, system coding, and exterior and hardware design, including the controller. There is also storyboard planning for plots and characters for Nintendo-owned licenses to help launch the console, layouts for different language versions, etc. Of course, the design and production of each specialized component will have to be done through individual projects. Yet they end up being part of a wider program because they are interdependent with all the other components for the final console. A program is also necessary because to deliver the final console on schedule, a greater degree of governance has to be used. It must ensure that the projects run as planned so individual delays do not hamper the overall output of the program: a finished, completed Wii console. What do you think? How do you know when program management is your best option? |
