The new operating model for project teams: Balancing flexibility and standardization
June 25, 2025 | Live Webinar
Viewing Posts by Geoff Mattie
Gain Executive Buy-In for Project Requirements
Categories:
Project Requirements
Categories: Project Requirements
| No matter what industry you work in, chances are you've had to build a long list of specific requirements to help define project success and to identify project risks. In many cases, you're required to align with your primary stakeholders on these requirements before you can move to the next project phase. These stakeholders are likely high-level executives who come from the sales or marketing side of business, or who are senior enough to have bypassed getting into the fundamentals of a project. Whatever the case, you're now left with the challenge of presenting them with these requirements. If they don't agree or understand your direction, you can't proceed on the project. If you're lucky, your stakeholders believe they hired you and your team because you're the experts. In this case, the presentation is more about showing them you've done the work and the next steps, instead of actually having to get their buy-in. Conversely, you may find yourself in a situation where many of the requirements need to be discussed and debated among the stakeholders. No matter which of these situations you're in, I've found that this three-step approach works best when presenting requirements to executives: 1. Divide the requirements into categories that will vary depending on the type of project. For example, if you're producing a software solution, your categories may be "security," "user interface," "connectivity," and "primary functionality." 2. When you have determined your categories, summarize the high-level direction being defined by each of the micro-requirements under each category. If there is a particularly divisive requirement and you anticipate debate, you should pull that requirement out and highlight it with its own slide. For instance, if you have decided to develop using Java and this needs to be discussed, or specifically approved, make sure that item is highlighted. 3. For all categories of requirements, create a list of pros and cons for the recommendation, and provide justification for the choice the team made. For documentation purposes, I would also include a check box that indicates agreement or disagreement from the stakeholders. Presenting detailed requirements to executives, especially in a limited time frame, is always a delicate operation. In my experience, following this approach will ultimately help you get the support you need to move forward in your project's next phase -- without risking a drawn-out approval process. What techniques have you used successfully to gain executive-level buy-in on project requirements? |
If Project Managers Had Life Tenure...
| I recently heard an interview with Antonin Scalia, an associate justice of the Supreme Court of the United States, regarding the rulings he has handed down over the years. The reporter wondered if Mr. Scalia ever worried about public backlash or the opinions of his fellow justices. Mr. Scalia simply replied that he didn't worry about that. He has life tenure, given to him by the U.S. government. He believes that tenure allows him to do and say what he thinks is right and not worry about how it will affect his career or colleagues. This answer had a profound effect on me. I often wonder if I am "doing the right thing" when I make decisions at work. I try, but I would not be honest if I did not admit that the career survival instinct hasn't kicked in once in a while. Perhaps sometimes I compromise on issues that I know are not good for my projects or my team. But I'll give the client the answer they want to hear, or perhaps tone down the weekly status report to avoid stirring the pot when there are real issues to discuss. I've now started applying what I will refer to as the "life tenure" rule to all of my decisions and activities. I try to look at a decision or situation through the lens of "If I did not have to worry about politics or personalities or self-promotion, would I still make this move?" I have to say, thankfully, that I appear to achieve that about 90 percent of the time. But clearly I think that can improve. I know it is naive to think that someone could or should perform their job as if they could not get fired. Or to think that if we all had that freedom, that we would always make the right decision. But it is an interesting concept to ponder, and a fascinating test to apply. Think about it: How would your professional life change if you had life tenure as a project manager? |
The Strategic Role of Project Management
Categories:
PMI Pulse of the Profession
Categories: PMI Pulse of the Profession
| I have a bit of resentment for organizations that view the role of a project manager as that of a 'traffic cop.' That is, as someone who simply ensures that requirements are documented, meetings facilitated, conference call numbers set up and everyone has their assignments in on time. To be sure, these are all important facets of a project. But I believe that any qualified project manager should be performing these actions as a reflex. In other words, this is not the primary role of a project manager but simply the basic administrative tasks of a much bigger role. That's why I was pleased to see the results of PMI's 2012 Pulse of the Profession report. Among many interesting findings, this observation hit home: Research conducted with senior project management leaders on PMI's Global Executive Council found that the most important skill for managing today's complex projects and programs is the ability to align the team to the vision of the project and design the project's organizational structure to align people and project objectives. This is the key to the future growth and a value-add of project management in today's organizations. If your company is not positioning project managers to help define, communicate and drive the strategic vision and goals of the projects project managers are responsible for, it is under-utilizing their resources. Project managers should not view themselves as simply the administrative support team for a group of subject matter experts and executives. They should take ownership of the overall success of the projects they run. This goes well beyond meeting the key performance indicators that have been set out for them. It also includes recognizing and providing the strategic value of the project to the organization. Beyond understanding the fundamentals of project management as laid out by A Guide to the Project Management Body of Knowledge (PMBOK® Guide), you should also take the initiative to know your business and the industry in which you work. This way, you not only recognize the obvious success indicators but also the more subtle success factors -- and risks -- of the decisions you and your team make. Take heart, Project Managers. It appears our true value-add is finally starting to be recognized. But also take heed: You must up your game to ensure you remain valuable in today's project management field. How can project managers help align projects to organizational goals? To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |
Guidelines for Project Clients to Enable Success
Categories:
PM Think About It
Categories: PM Think About It
| I recently witnessed two projects executed within weeks of each other. Both projects were related to the rollout of major technology solutions for significant, well-established corporations. What was different about the projects were the dynamics between the client and the project team -- specifically, the way the client engaged and worked with the project team. One project was successful, and the other was not. In my opinion, the success as well as the failure was largely because of the dynamics between the client and project team. I am definitely not implying that any project gone awry is the client's fault. In fact, I believe it's the project manager's primary responsibility to facilitate all points below. But unless the client is willing to observe and adhere to these guidelines, the project is already in jeopardy. Think about it. Here is a working list of guidelines that can help clients and other stakeholders work with a project team and deliver a successful project: 1. Be transparent. A good project team realizes there are going to be unique variables and circumstances it will need to address. Be upfront and candid with the project team about the challenges or risks in accomplishing the project goals. It is much more productive to get everything on the table upfront versus waiting for it to be discovered while executing the project. 2. Stay engaged and responsive. One school of thought says a good client stays out of the way of a project team and without too much micromanagement. This can be true to some extent. However, clients must work with the project team to ensure there are open channels of communication. Information or clarification must be provided quickly and concisely, and preferably in writing. Ideally, one or two people on the client side have the knowledge and authority to speak for the entire client team. This is especially important when providing critical input such as requirements, milestone approvals and strategic guidance. Without this representation, the project team has to chase down information, and there is greater risk of them getting it wrong. The project manager must facilitate these activities and provide the framework in which they occur, but this is a two-way street. As a client, if you cannot make the time and emotional commitment to communicate, then postpone the project until the time is better. Otherwise, we all risk having to do it over again. 3. Be decisive and time sensitive. Recognize that there are going to be hard decisions to be made in terms of requirements, tradeoffs, budget, timing and resources. If a decision cannot be made on the spot, define a window of time in which you will get back to the team with an answer and respect that commitment. As noted above, if it's going to take time to get an answer, let the project team know this ahead of time. 4. The laws of physics still apply. As nice as it would be to bend the laws of physics, project teams are not capable of making three-day tasks in just two. Project managers do sometimes pad their timelines to allow for project creep or addressing other unseen emergencies. But recognize that this is done due to experience from previous projects and is an effort to account for the "unseen" challenges that inevitably crop up in your efforts. Forcing a team to schedule its project activities in exacting increments for the sake of impressing company executives, for example, introduces a risk that some unforeseen event will cause that project to run late. What other guidelines would you add to this list? Read more from Geoff. |
Are You Sure Your Project Information is Secure?
Categories:
PM Think About It
Categories: PM Think About It
| Fellow blogger V. Srivinasa Rao recently wrote an interesting post about the Global Distribution Model 2.0 that is launching soon. The model holds a lot of promise and is a great framework for implementing mobile global communications tools. Today, the fastest rising communications and computing technology is mobile. And while this development provides exciting possibilities for improved project efficiency, it does not come without risks. I'm focusing specifically on devices with a mobile operating system, such as iOS, Android, Windows Phone 7, Blackberry or Nokia. The reason for my concern is the speed of adoption for the devices. They now play a role in every project I manage. It may be simple communications such as email between team members, text messaging and calendar functionality, or more sophisticated uses such as remote access to project data, project management software or even video conferencing. Yet 90 percent of the time, I find that no one is really thinking through the implications of using this technology. Think about it: With this expanded communication comes an increased risk that your project's confidential or critical information could be exposed, intentionally or unintentionally. This information can be controlled fairly easily by IT departments on laptops, but mobile operating systems don't allow for the same kind of security just yet. You must be wary of how information may be getting communicated over your mobile device. Information "attacks" can come in several forms. At an event where "free wireless access" is offered, for example, someone who wants to gather data illegally can set up a US$50 wireless router, name it "[Event Name] Wireless" and watch as attendees innocently connect their devices to communicate with the rest of the team. Simply leaving your Bluetooth enabled in public locations can open you up to attacks. It doesn't even need to be something that devious. All that needs to happen is for one of your team members to lose a device that has regulated data on it. In the United States, you'll have to officially report the incident to the Federal Government. The key takeaway here is that as our world expands, we are being given exciting new ways to coordinate and communicate with our team members across the planet. We should take full advantage of this. But we should do it with our eyes open. How do you protect your data on a mobile device? |