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? |
When Project Decisions Get Difficult
Categories:
Teams
Categories: Teams
| Two important members of your project team recently ended a six-year romantic relationship. While they're both trying to keep their domestic problems out of the workplace, the inevitable tensions between the two ex-partners are obvious and are causing the team to split into two camps. The situation is affecting the team's ability to achieve a successful outcome on a high-stakes, high-pressure project to deliver critical capabilities to a customer. You've tried working with both team members and sought assistance from the HR department to minimize the issues with limited success. Each of them is vital to the delivery of the project's objectives. However, you've suggested to both that perhaps the team would be better off if one of them moved onto another job. Unfortunately, neither have a viable option. Your analysis of the situation is as follows: If either of the people leaves, the team's ability to deliver the project will be reduced by 10 percent. If both of them leave, the team's ability to deliver the project will be reduced by 20 percent. If both stay, the team's ability to deliver the project will be reduced by 25 percent and will get worse over time. The customer cannot afford any reduction in the team's capability to deliver this business-critical outcome. As the project manager, what would you do next? Post your comments below, and in my next blog, I'll summarize reader reactions and look at the options. |
PMOs Shouldn't Forget the Project Manager
A project management office (PMO) usually follows one of three styles:
We aim to avoid direct ownership of projects except in specific cases, such as when the project is located where local project capability is low or the project has gone badly wrong. In this latter case, we aim to "own" the project for as short a time as possible and always develop a transition plan back to the original project manager if possible. The PMO should generally not be considered the "mother of all project managers." Rather, it should be seen as the body that helps develop the best project managers -- the ones who are facing stakeholders on a day-to-day basis, the ones experiencing the meeting of theory and practice. A PMO can:
Let's not forget the project manager. |
Can Agile Conquer the Physics of the Triple Constraint?
| I recently saw a presentation from an advertising agency that claimed it would be able to do what no other company had: It had figured out how to deliver complex projects (in comparison to other digital advertising projects) inexpensively, on spec and faster than any other firm in the pitch. It was more of a tag line, so there was little by way of explanation behind the claim. I held my tongue during the formal pitch, but made a point to ask the presenter a few questions after the meeting. Primarily, I wanted to know if he had heard of the triple constraint. The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality. Some assert that several additional factors come into play when discussing a project's success. I agree with this, but I disagree with removing the triple constraint model from training, as I believe it's such an easy concept to teach, understand and enforce. My confidence in the triple constraint made it hard for me to believe that anyone had truly convinced themselves they could beat what is, essentially, physics. But sure enough, I got a very firm response from the organization: "We are able to deliver this service because we take an agile approach in our production processes, making us more efficient and thus able to deliver more value for the customer." Confused, I pressed a little further. "As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint. Agile simply prioritizes the tradeoff as one of scope rather than time or quality," I said. Of course, it wasn't a discussion I was going to win in this setting. Looking around, I saw that the speaker's entire management team had bought into the theory and were smiling proudly at their triumph. I let it go. But it struck me how much confusion still seems to be out there around the triple constraint and the ability of newer methodologies such as agile to overcome it. How many of you have had your management tell you to explore agile as a way to get your current project work done faster without sacrificing any of the three pillars? And how many of you still use the triple constraint to help you explain the basics physics around project execution? |





