Project Managers in the C-Suite
Categories:
Career Development
Categories: Career Development
| I've seen some articles and heard some commentary lately that lament the fact that there doesn't seem to be a clear career path that leads from project management to the so-called C-suite, also known as the "executive suite." Where I work, there is no direct path that leads from project management to the executive ranks. Occasionally, a person who has worked as a project manager becomes an executive, but it's certainly not the norm. From my own point of view, this isn't a problem -- on the contrary. Had I wanted to be a "line" executive, I would have stayed in line management. I chose project management because I saw it as a means to manage the kind of work that I really enjoy most: the realization of ideas. For me, career growth means managing projects that are more important, more valuable, more interesting or just more fun. Often, this can mean bigger teams and bigger budgets, but for me, that doesn't necessarily translate into bigger thrills. Career growth does not mean at all that I need to become an executive to feel fulfilled. I see project management and executive management as complementary, but very different, skills. To me, that means that the two fields will appeal to two very different kinds of people, depending on individual temperament. Project management is very tactically focused. It's all about defining the job and getting it done. It seems reasonable to me that the kind of person who manages projects is also tactically focused, and temperamentally oriented toward the realization of ideas. On the other hand, I see executive management as more strategically focused, more about defining a strategic vision and deciding which projects to undertake to realize that vision. It seems reasonable to me that the kind of person who becomes an executive is also strategically focused, and temperamentally oriented toward defining strategy and how to achieve it. What do you think? Are project managers under-represented in the executive ranks? If this is true, do you see this as a problem, generally speaking? Personally speaking? Do you have aspirations to become an executive? If so, do you see being a project manager as an obstacle to those aspirations? Do you believe that project managers are temperamentally different than line managers? Why or why not? Read more posts from Jim De Piante. Read more posts about improving your career. |
What Do You Look for in a Collaboration Tool?
Categories:
Tools
Categories: Tools
| With so many project management collaboration tools out there, what is a useful, intuitive and inexpensive tool to use? It all depends on what you look for in a tool. I look for the ability to assign tasks to team members or teams. I also like to be able to add notes and collaborate with team members through the tool, specific to the tasks they're assigned or the work they are doing. These capabilities cut through many unnecessary meetings and allow you to see real-time progress of the assigned work. I use a web-based software called IntervalsTM. I create my projects and tasks, and then add my team to the projects and assign each of them their respective tasks. While I may create an MS Project-based project plan, I would use Intervals to manage the actual tasks, time and budget. It's also a great tool for assessing how much time various tasks take and getting a more accurate measure of the time spent on the tasks. This tool has built-in timers for each task and general timers that make it easy to track your time. Timesheet management is quite easy as well. I get my team to submit the hours they spent on a regular basis. At the end of the week, they submit their timesheet, which I either approve or reject -- it all happens online. Another great feature is the executive role, which allows an executive or sponsor to see the latest progress on a project without having to be involved in any other details. The progress can be seen at any time online, by anyone provided such access. What are your favorite collaboration tools? Are there any tools you use that achieve all these abilities? The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI. |
Avoid the Agile Logjam
Categories:
Agile
Categories: Agile
| Not all Agile teams are created equal. Some commit to their work and complete requirements throughout -- not just at the end. Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all. What makes these teams different? Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more. Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action. One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another. If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned. How have you avoided Agile traffic jams in your projects? Has splitting stories to a manageable size helped avoid bottlenecks? |
Finding a Project's Intangible ROI
| If you're new to project management, you might be surprised to learn that some projects -- maybe some of yours -- do not generate any actual profits. That can make it difficult to demonstrate how talented you are as project manager and how great your project delivery team is. So, how can you show you've created value if you cannot show revenue or profits as a direct result of your project? Look at ROI in a different light. Instead of using profits as a benchmark, consider intangible benefits, such as cost-savings that will result from the project, or a positive swing in public relations or team dynamics My team and I were working on a project that involved automating a conference room. A user could walk into the room, push a single button and the automation would do the rest. The project didn't generate any profit, but the feedback from stakeholders was 100 percent positive: My team had created an environment that worked as advertised and made users' work lives easier and less frustrating. And that translated to a huge upswing in stakeholder influence. When we needed buy-in on the next project, the stakeholders were more than happy to offer support. They even understood if the project would affect them negatively (i.e. space being unavailable for use during project, or a feature being disabled for a short time). It may be hard to say that stakeholders' good graces (for example) increased by exactly 42 percent, but it's very obvious when your ability to influence them has increased. Things seem to just run more smoothly. Have your projects generated intangible ROI? How have your project teams benefited from it? |
How Arguments with Stakeholders Hinder Project Managers
| Arguing with your stakeholders is never good. The basis of an argument is to defend your position while defeating the other person's in the process. It's easy to suggest using active listening to understand the other person's viewpoint, but this advice overlooks the inevitable build up of emotions inherent in any argument. Asking the help of a third party to mediate an argument with a stakeholder can be very useful. First, the presence of an observer helps contain excessive emotions. Secondly, a third-party observer can bring fresh insights to help move the argument to a constructive discussion and, ultimately, a solution. Transitioning from a sides-based argument to an "us"-based solution does not require the third-party observer to necessarily solve the problem. Rather, the mediator should help those arguing to develop a solution. An ancient legend demonstrates this concept beautifully: A farmer died and left his herd of 17 camels to his three sons. In his will, he left half of the camels to his eldest son, one third of the camels to the second son and one ninth of the camels to his youngest son. The three brothers were having great difficulty working out a fair way of implementing their father's will and could not agree on who would have more and who would have less than the amount willed. Before their relationship became too stained, the brothers went to visit a wise old woman who lived in their village to seek advice. She told them she could not solve their problem but would give them her only camel if it would help. The brothers thanked her and took the camel back with them. With a herd of 18 the problem simply disappeared; the first brother took 9 camels, the second six and the youngest two. But, 9 + 6 + 2 = 17, so they gave the spare camel back to the wise old lady with their thanks. The point of the story, from a project management perspective, is that belaboring arguments with stakeholders will only succeed in delaying the project. For the sake of keeping the project within the triple constraints, it's best to resolve arguments promptly and for the good of the project. In your projects, how have you handled arguments? Do you seek help before positions become entrenched? |





