Gaining Acceptance
| Every project has an acceptance criteria defined for deliverables but I wonder how many of us get the explicit acceptance from our stakeholders. In a long-running project we keep delivering to the client but rarely bother to get a formal approval on the delivery--which may create problems at the end of the project. I've experienced problems in a couple of projects because of no formal acceptance of the delivery. Ideally, for each delivery you should ask for explicit acceptance from the authorized stakeholder and communicate that authorization through weekly status reports. This will help you in the final acceptance of the project and initiating the maintenance phase, which would be a billable effort. Then the project team should follow up with the client to get a sign-off on specification, design, code, etc. Am I alone with this problem or is it something others have faced as well? |
General Motor's PMO
Categories:
PMO
Categories: PMO
| As director of the enterprise program management office at General Motors (GM), Paul Checkowsky oversees program management offices around the world in different functionary areas like sales, manufacturing and supply chain. He took some time to answer a couple of questions about the state of the project management office (PMO) at the auto giant and throughout the world. How has the economic downturn affected the PMO at GM? From an economic standpoint, we've got to be a lot more careful about getting the most value for our money. A couple of examples: In the past, we've focused a lot on quality assurance of the process--making sure that people are following all of the steps. That's very time-consuming and can be expensive. Now we've built the quality-assurance process into the steps. We no longer have checkers checking peoples' work. We basically built the quality into the process, so that at the end, we don't need to perform a final quality review. We are also doing more backward planning rather than forward planning. We are making timing and content commitments to our business community at the beginning of the year and we are holding the project teams to those commitments. We then plan backward to determine what and when we have to do to achieve the commitments. Many project teams are not comfortable with this approach but it does force teams to get off to a fast start and forces them to resolve issues in a timely and efficient manner. The other thing we've been doing is instead of being a policing organization, [the PMO] is now much more involved with mentoring upfront-- making sure the project teams are aware of the processes and helping them know where they might encounter bumps in the road. Do you think more organizations are realizing the value of the PMO? They are. Actually, in the last six to 12 months, I've [received] a lot of feedback from individuals saying that this new approach--where the PMOs are actually part of the teams doing the work--is very effective. [Organizations] themselves are finding ways to leverage these PMO capabilities and this expertise especially helping to identify and resolve integration issues, mentoring of enabling processes and eliminating deployment roadblocks. So I think it's been very positive, and I think it's here to stay. Mr. Checkowsky says it's hard to say what is going to happen with GM's EPMO in light of the economic situation. At the time of this interview, news headlines speculated the organization's possible bankruptcy. Overall, however, he says that "people are going to expect more with less. That's not going to change. We're going to have to do a lot more with fewer people, less money and less time." Despite the challenges, however, he says there are exciting opportunities out there. "Because of the conditions that we're facing, this is really an opportunity for us to put some changes in place that we've considered in the past. "Before, there wasn't a burning platform. Now, there is. So people are much more open to changes and new ideas--where in the past, they'd be, "This has worked for us all of these years. Why change?" Now people are realizing they do need to change. It's actually an opportunity to put some of these new approaches in place. We've just got to make sure that they're effective." |
The Power of Acknowledgment
Categories:
Communications Management
Categories: Communications Management
| When the University of Maryland University College Graduate School of Management & Technology e-Business and Project Management Program adopted my book, The Power of Acknowledgment, for one of their courses, I began leading live, interactive online seminars once a semester. Several students sent me discussion questions ahead of time. These questions from these adult learners in critical jobs have been very thought provoking, and I wanted to share my thoughts on one of them. Others to follow... Question: "How do I handle a supervisor that doesn't give acknowledgments? ... It has gotten so bad, that I'm happy when he doesn't come to work and I have to deal with his supervisor who has a totally different management style. I think you may have some ideas that I can use." And I do: • Create a culture of appreciation in your organization. You personally can be a champion of change in your team's or department's or your company's culture. I know this sounds difficult, but you can start the process by making sure to acknowledge both your peers and the people who report to you in a heartfelt and authentic way. Your example will start generating a desire to "pay it forward" and after a time your manager won't be able to ignore the shift he or she is seeing around him or her. • Acknowledge upwards! I believe our managers or bosses are among the most under-acknowledged people in the workplace. And even a boss who doesn't give acknowledgment can see and feel the impact of being acknowledged truthfully and in a heartfelt manner. And yes, you may have to really search for that acknowledgment but I promise you, something worthy of being acknowledged for is there. • Speak as off the record as possible to your "grand-boss." (i.e. your manager's manager.) There is some risk here of word getting back to your manager but it depends on how desperate you are, in order to see if this approach makes sense. • Know how much you can take. If the lack of acknowledgment and appreciation is too devastating for you, you may have to request a transfer to another department or even leave the company. This is not an action to consider except as a last resort. E-mail me your questions about establishing a culture of appreciation throughout your organization, and about using the power of acknowledgment to create miracles on project teams, in your departments and throughout your organization. You will be amazed at the results once you start using the power of acknowledgment. Editor's Note: Judy Umlas is author of The Power of Acknowledgment, published by International Institute for Learning Inc. through IIL Publishing, New York. |
Projects and (Organizational) Culture
Categories:
Teams
Categories: Teams
| There's limited time today to implement projects. And even when we set a target timeline, we are challenged to deliver results faster and at a lower cost, while still meeting--or exceeding--the same quality standards. It's been my observation that the success of organizations with this depends on how well they connect their project management processes with their business delivery teams. I also think, however, organizations need to pay more attention to how they connect their project management processes with their organizational culture. Here are some key principles to keep in mind: 1. Define and sign off on project parameters. This must be done by the organization's key decision-makers on the financial and operational sides. 2. Define project teams and stakeholders early on. Without this step you will end up going in circles to figure out who has what authority and influence. 3. Identify the structure of the organization and where project team members fit in. This is critical to understanding the influencing factors behind the decision-making affecting your project. 4. Understand that a project team is a microorganism of an organization. It feeds the organization with the required inputs that make it viable for the project team to deliver requested solutions. 5. Establish strong leadership and a clear, single path direction from the project manager, with adequate support and authority levels to perform tasks. 6. Personality, management style and values have to be similar or complementary among all project participants. In other words, the core project team interacts not only with itself, but project participants from other functional areas. The choice of individuals to connect to the project will either make or break the total project team. 7. The project team has to be in sync with other team members provided by the functional teams, in a way that project resources can utilize existing organizational processes, systems and information to deliver project results without having to reinvent these same processes within the context of the project. |
Improving the Testing Process
Categories:
Information Technology
Categories: Information Technology
| I work with an IT software development organization, so most of my posts are specific to software development projects. During the testing phase, we typically experience the following problems: 1. We expend approx 15% to 20% of the development effort in the bug-fixing phase. 2. Our team discovers a lot of missing functionality during the testing phase. 3. Quality assurance (QA) and development teams have different mindsets, so they understand the same feature in different ways. 4. Test cases written by the QA are a conversion of a software requirements specifications document into an excel format. 5. During and after the coding phase, the developer doesn't often test the application himself and instead leaves everything for QA. He tends to believe bug identification is QA's task and that the developer should only be responsible for fixing bugs. I think the software testing cycle works on the 90:10 rule: Ninety percent of the project takes 10% of the allocated time, while the remaining 10% takes 90% of the time. After expending a lot thought on this process, we came up with some solutions that may reduce the testing and bug fixing cycle: 1. Let the QA and development teams both review the requirements and get necessary clarifications from the client. 2. Ask the developer to give a presentation of his project understanding to QA and his module lead. 3. Have QA prepare the test cases. 4. Ensure test cases cover the functionality as well as the user cases and scenarios 5. Have the developer review and log defects, too. 6. After the completion of the coding phase, ask the developer to run high priority test cases prepared by QA. 7. The developer should submit the test log to QA. 8. QA shall start the testing. 9. Each discovered bug should have a corresponding test case ID. If the test case doesn't exist for the bug, then QA should add a new test case for it. This will ensure the test cases have covered all the use cases. 10. In the test log for each failed test case, enter the bug ID. This will ensure all bugs are raised and tracked to closure. 11. Perform the Root Cause Analysis (RCA) for each bug and improve the coding process. 12. Track the bugs raised by QA versus the bugs raised in user acceptance testing or bugs raised in production. 13. Test cases should be data-oriented, and QA should be trained enough to write simple SQL (Structured Query Language) queries. 14. The test log should show the number of rounds executed with the number of test cases that have failed, passed or have not been executed for each round of testing. 15. Track the actual effort spent in the testing and bug fixing phases to better plan for the next module or project. |
