|
How Project Managers Can Demonstrate Business Acumen on Every ProjectbyBusiness acumen isn’t just something that executives or other higher-ups have—it’s a skill that project managers can access and exhibit on a regular basis and within each project, no matter the size of the endeavor or type of industry. |
|
Preventing Fiber Cuts in India: Embedding Utility Coordination Into Project DeliverybyThe fiber cut problem in India is not merely the pace of infrastructure growth—it is the absence of safeguards to ensure that what has already been built remains functional, protected and sustainable. These eight steps can improve utility coordination and prevent cuts. |
|
Why Project Managers Need to Push BackbyHow much do you challenge the directive? If project managers are always going to go along with what they are asked or told to do, then there really isn’t a lot of point in them being there. |
That is my excuse for waiting until Sunday evening to study this week's allotment: the first three chapters of the PMBOK Guide ("A Guide to the Project Management Body of Knowledge" available from the Project Management Institute).
I have had excellent training covering the material, so I can get away with a review, though I will have to spend more time on the subsequent chapters, since they specifically cover the nine knowledge areas. The first three chapters are the introduction, "The Project Management Context" and "Project Management Processes," the last of which really is crucial for understanding the chapters that follow.
Like most Americans today, I want to be doing two or three things at once or I feel like I'm wasting time, so I want my study time to count not only for the exam, but also for my current projects. Let's see what the first three chapters have to say.
As my husband watches the latest Star Wars movie and my 2-year-old scribbles on my PMBOK, I read the definition of a project. I have met a few folks with the title of Project Manager who would question their titles if they knew that a project, to technically be classified as a project, is supposed to end. Some folks would more accurately be described as Product Managers.
The project managers in my department fulfill both roles. Our projects end one week after delivery of the product, when we have our last weekly status meeting. We then conduct our internal project review, and the PM's assume the role of Product Manager...an ongoing role in which we field questions and coordinate troubleshooting, and the work never ends.
The "Introduction" chapter also gives a very brief overview of the Project Management Knowledge Areas and wraps up with helpful details about how project management relates to other management disciplines.
The second chapter further describes the difference between projects and products while discussing the Project Life Cycle, which will vary from company to company and even from project to project. For instance, on our team the project does not begin until our assessment indicates that development of the requested Web-based application fits within our department's charter. Another project team might make that assessment or feasibility study a project of its own, or the first step of the project. The project life cycle also determines when the project ends.
The most memorable and relevant information for me in this second chapter is the discussion about project stakeholders. Having them properly identified and participating with our project team would have saved some serious re-work time on more than one project.
The goal is to manage stakeholder expectations. The challenge is that stakeholders can have differing objectives. In our case, a stakeholder is any person or group who will use or be affected by the use of the Web-based application we are developing.
One drastic example of stakeholders with conflicting objectives occurred several years ago, when the new process adopted by one department significantly increased the workload for another department. If your customer is the one streamlining their process, you might think it is their job to deal with the department that their new workflow affects.
Let's look a little further down the path. What if the senior management of that other department refuses to accept the increased workflow, or to interact with that newly developed software? Perhaps they correctly identify that they cannot spare the time for their staff to be trained, or there is some other reason that they can't use the new process or product. If your project team has half of the year invested in this project, and the end of the story is that it is never used, you will have a new appreciation for the term "stakeholder." Everything you do to identify your project's stakeholders and to manage their expectations is good for your project.
Chapter three, "Project Management Processes," talks about the "triple constraints" and about these major topics: Project Processes, Process Groups, Process Interactions, Customizing Process Interactions and more. As I said earlier, this chapter really is key to more easily absorbing and applying the wisdom in the chapters that follow.
I'll let you read that chapter for yourself. Not that I haven't read every word, and not that it is getting late. I just know that your review of that single chapter will help you see what I have always liked about project management: Virtually every aspect of this profession makes sense (unlike a lot of other disciplines). How can you not like a profession whose sole purpose is to get the work done successfully, while helping the project manager work effectively and look good?
Now, if you are studying along with me, let's see how successful we are and how much we can learn from the next scheduled-for-study chapters, "Project Integration Management" and "Project Scope Management."
Donna Boyette is a busier-than-ever Project Manager for a large telecommunications company in the
|
"Interestingly, according to modern astronomers, space is finite. This is a very comforting thought--particularly for people who can never remember where they have left things." - Woody Allen |
