“Things Your PMO is Doing Wrong” is the title of a PMI book by by Michael Hatfield (2008). Coming from a real-world perspective, the book parallels insightful organizational management discourse that I have heard. Says Hatfield, “Leveraging organizational power and influence [over behavioral compliance] does not advance project management maturity….” This is broken out into the following PMO mistakes:
- Organizationally enforcing compliance to project management techniques
- Blaming the organization (not their own naive policy) for politics unraveling a successful adoption
- Expecting ROI to substantiate project management techniques
- Expecting training to result in participation or good practice
- Expecting internal documentation or external guidance to further good practice
- Missing earned value, critical path, and cost and schedule performance assessments for projects
- Standardizing on software packages to process and deliver cost and schedule performance information
- Restricting decision-makers’ latitude in taking managerial actions
- Suggesting to decision-makers that they need to work harder or take a potentially unpopular position
- Exempting from the techniques any organizational work that qualifies as a project
You desire to make projects leaner. But you want to avoid the trap of encumbering them with bureaucratic red tape. Your focus should be on praising teams that practice lean principles and providing education and aids to teams with new projects. Use the list below as a guide, and publish your own quick-references and checklists for lean best practice in your organization:
- Stakeholder & Resource Management
- Assumption & Dependency Management
- Code Standards
- Risk Management
- Source Control
- Change Control
- Task Monitoring
- Operations Handoff
- Retrospective-Project Closing
- Hot Fixing
- Business Outcomes
Every iteration or release of a project requires some form of estimation. Schedule estimates generally start as ballpark numbers that need to be adjusted during the project. As factors stabilize, initial estimates can be more sure. You need to have stability in who the team consists of, their allocation, the completion of estimated scope, and control over additional scope that is not estimated. In addition, the average size of future scope items need to be close to the average size of historical scope items, which we will call “ave. hist. size.” The following facts make estimation very easy in a stable project environment.
- Work days equals Number of scope items of ave. hist. size (s) divided by Throughput
- Throughput equals Number of historical items that the same team fixed (a) divided by Number of work days required for all items
Combining the above, you have the formula, d = s / (a / w).
Say your team fixed 150 items (a) over 100 work days (d), and you have 30 items in scope. In addition, 8 of these items are twice the average size, or equivalent to 16 items of ave. hist. size (s). Therefore your total scope (s) is 30 – 8 + 16, or 38
Plug these numbers into the formula above, and you have d = 38s / (150a / 100d) = 38s X 100d / 150a. Remembering your Algebra, you know that because “s” and “a” are the same unit, these cancel each other. Therefore, 38 X 100d / 150 = 3800d / 150 = 25.33d. You can confidently expect to finish development of the 30 items within 26 work days plus a small buffer.
Notice that the scope items are not estimated individually, but as a group. This is the key to both simpler and more accurate estimation.
Tags: estimation, team capacity, committed scope, throughput, resource allocation, stable project environment, staying on schedule
I don’t think anyone would disagree that working well with sponsors and other stakeholders is an important part of the project environment. I’m convinced it’s even more important now as the line between work and projects becomes harder to recognize. I think this evolution is a good thing. What’s more, as it pushes project leaders to become more invested in the business value of what their doing and compelling them to work and collaborate more closely with line-of-business managers to make sure what they’re doing will provide maximum value, I think projects will be more successful and organizations will ultimately reap the rewards.
With that said, the type of relationship you foster with your project sponsors and stakeholders is largely up to you. We all understand that everyone on the project team (including the project sponsor) has a role to play that helps determine whether or not a project is successful or struggles. Unfortunately, in many instances, the sponsor might not understand his or her role. With that in mind, here are three suggestions for keeping sponsors engaged and participating:
- Schedule a regular meeting (usually monthly) with sponsors, team members and other important stakeholders: This might be a good time for a quick status update; but more importantly, it’s a time for reinforcing the value and significance of the project in terms of business value and sponsor’s commitment to helping the team.
- Educate the sponsor on their role as part of the team: The sponsor has an important role as project advocate to communicate with other stakeholders and provide visibility to executives. Don’t assume your sponsor understands his or her role, you may need to provide a little guidance so they know what they’re supposed to do to help keep the project moving forward. In a recent podcast, we spoke with Peter Taylor, the Lazy PM, about the sponsor relationship. You might want to take a few minutes to listen to what he has to say about the PM/sponsor relationship.
- Don’t neglect impromptu one-on-one time with the project sponsor: Make sure your sponsor is willing to have the occasional informal meeting when needed. It’s not only important to cultivate the relationship with your sponsor—your success impacts their success within the organization.
Sometimes an engaged sponsor is the difference between a successful project and one that fails. Tools and approaches that facilitate sponsor/stakeholder communication can make this a lot easier. It’s never a good idea to allow your project sponsor to sit on the sidelines and avoid his or her important role.
What are you doing to keep your sponsors involved and engaged? Should we add something to the list?
—Ty Kiisel, AtTask
[Reblogged from http://it.toolbox.com/blogs/strategic-project-management/3-keys-to-working-with-project-sponsors-50960]
· When my boss wanted to re-evaluate a temporary staff requisition that was vacated halfway through the term, and I was in the process of backfilling
· When a product needed user acceptance from a supervisor, who the phased data migration would have immediately cut off from using the legacy system
· When I did not know about an inter-operating product while writing a functional spec
· When I learned about a partner’s reorganization after forming a joint requirement-gathering strategy with the outgoing partner-stakeholder
· When inheriting a project after Initiation and functional specifications had been completed
· When believing my boss who said that his sign-off represented upper management’s buy-in
· When the project’s marketing leverage changed midstream on a project, and unsuspecting new stakeholders were created
· When my boss left the company midstream on a project, and his boss was not as hands-off as she appeared to be
What do you think? Would there be little impact from any one of the following 5 errors in handing over an application to Operations?
1. Overestimating servicing capacity
If servicing capacity is not adequate after an application is released to production, service requestors will feel that support is unreliable, and their dissatisfaction with the application will increase. Had capacity been estimated correctly, users may not have accepted the app for release until further capacity planning was done.
2. Inadequate service training or documentation for technicians
It is not enough to give technicians lists of procedures and decision flowcharts. They should have an understanding of the system. Moreover, a troubleshooter needs deeper understanding, the same as a super user.
3. Treating every service request as a system problem
Service requests sometimes are best resolved with user training or corrections to business processes, instead of updates to the system. For instance a manager may ask for a custom report that includes classified information. Clearly the service tech needs to follow a decision matrix that routes this request appropriately, possibly requiring the requester to re-form or reject the request.
4. Not leveling potential service requests
Creative licencing policy and servicing plans can help smooth out potential usage spikes and peak service volumes by encouraging users to become more self-sufficient or find better alternatives. No, the app and operations team do not need to be the answer to every need. However, before implementing these policies and plans, the limits of the app’s capability and servicing plans must be clearly communicated.
5. Allowing service requests to occur
Certain proactive measures can reduce, if not eliminate, service requests. They include user training, standardization of business processes, and environment upgrades (computers, browsers. Etc.).
If you still think there would be little impact from any one of these 5 errors, I am interested in what you think.