The Value of Reports
Categories:
Communications Management
Categories: Communications Management
| Developing reports is an art form--and it's one that every project management office manager needs to master. Well-designed reports contain large amounts of useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon. That information also allows stakeholders to extract trends and status. And if you deliver them in person or attach a note to highlight specific issues or messages, reports can form the basis of a targeted, purposeful communication. Some people simply like getting reports--and dropping those people off your distribution list make them more upset than you realize. This also applies to cutting content. As a rule of thumb, by the third month it's probably too late to remove sections or drop recipients without encountering some issues. Another benefit of reports is only starting to be recognized. Jon Whitty of the University of Southern Queensland here in Australia has been measuring the emotional effect of project artifacts. Based on Jon's work it seems a well-formatted report will in itself increase positive emotions. The project manager feels comfortable because she or he has a "proper report'' that is part of the "clothing'' every project manager wears along with their Gantt charts and other expected artifacts. And senior managers experience positive emotions because the existence of a well-presented report suggests control, order and capability. The challenge is to design reports that are relatively easy to produce, ask the right questions, are well-structured and well-formatted, and contain needed data. What are your experiences with reports? |
A PMBOK® Guide for the Trenches, Part 2: Schedule
| Last time in my post, PMBOK® Guide for the Trenches, I discussed scope. Now, I'd like to cover some basic truths about schedules that project managers need to know, but won't find in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). One vital truth that the PMBOK© Guide is clear on is that scheduling is only one aspect of effective project management, along with scope, cost, risk, communication, procurement, human resources, quality and integration. But you won't hear that from professional schedulers--no, no, no. It's often believed that the central tenet of project management is the ability to resource-load a schedule baseline into one of the more robust software packages that perform critical path analysis. This is part elitism and part what I refer to as "black box syndrome." Project team members are led to believe that if a certain software package is fed all the data it needs, then the push of a button will deliver all the management information needed to successfully complete a project. This, of course, is hokum, but I've seen it in many a project management office. On the other side of the coin, it's a fundamental truth that you cannot manage a schedule with a list of milestones or action items, no matter how elaborate that list may be. What tends to happen with action item lists or databases is that they essentially turn into, , polls and polls are not legitimate management-information systems. With a poll, there's always someone who has more recent information or more complete information than what's in "the system," rendering the data there unactionable. Note that I said the data in the system. There's a profound difference between data and information. Legitimate management-information systems process data into information using some kind of methodology. For schedules, this method is critical path. And it's a safe conclusion that there is no legitimate schedule management without critical path. For serious project work, a critical path network is absolutely essential. This no doubt contributes to the phenomenon of schedulers thinking critical path management is all that is essential in project management, with the other stuff kind of ancillary. I'm looking forward to everyone's comments. |
Breaking Your Commitments
Categories:
Career Development
Categories: Career Development
| In my previous post, I talked about work commitments. Sometimes success in project delivery requires breaking those commitments if they are not in line with your goals. If you need to break a commitment, I recommend the following steps: 1. Identify a commitment you have made that is not benefiting the project. 2. Consult with the project manager and/or supervisor whether this activity can be removed from your list. 3. Identify someone suitable to deal with this task. Seek advice from your manager when in doubt. 4. Once you've secured management authorization, transfer the details of your commitment to that person. 5. Advise the person to whom you originally made the commitment that the task has been reassigned to another person, and explain the reason for this action. Depending on your role and authority, you may be able to deal directly with the person to whom you made the commitment, and you can resolve the conflict without involving other parties. There's no magic formula for undoing what's done. But by breaking such commitments in this professional manner, you are renegotiating the terms of your commitments and earning trust and credibility. |
Veering From the Typical Career Path
Categories:
Career Development
Categories: Career Development
| I recently watched a Hindi movie called 3 Idiots. The moral was to follow your passion--which got me thinking... In the software industry I've seen examples of technical leads who were promoted to project manager based on the assumption that they'll perform just as well in that role. But in several of these cases the technical lead has failed in the new position. That's because project management is not about resolving technical issues. It has other parts: resource management, cost management, expectation management, etc. Companies shouldn't automatically follow the standard growth path for each role, whether it's for a software engineer, senior software engineer, technical lead or project manager. Rather, the path should be decided based upon an individual's capability and interests. A technical lead may be interested in business analyst work or quality-assurance activities instead of the project management role. Also, as individuals we should have the opportunity to follow our passion and not feel tied to a typical career path. What do you suggest? |
Is This Your Project Stakeholder--The Conclusion
| My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts. The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why? The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program. As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence. As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization. Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis. The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented. Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes. If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager. |
