Best Practices in Project Management -- or Better Practice?
Categories:
Best Practices
Categories: Best Practices
| Best practices in project management are tried and tested processes collected from experiences and lessons learned. They've been repeated and improved to produce consistent outcomes. They are documented as examples, baselines and measures. Project managers who favor best practices and processes believe it's unnecessary to "reinvent the wheel." They believe using best practices in projects has many advantages:
Best practices for projects from 10 to 20 years ago are outdated as technology and real time communications continue to evolve, for instance. More customers are aware of project management, resulting in changed expectations. And definitions of acceptability, constraints and assumptions may differ from the environment where these best practices originated. I agree that we shouldn't reinvent the wheel. However, I do stress that the wheel should fit properly in order to fulfill its purpose. Best practices are excellent if there is cooperation and consistency in an organization from top to bottom. Rigidly imposed processes that are unwanted and misunderstood cause problems and restrict new thinking. Project managers should use best practices but they should build, fine-tune and improve them to fit an organization. Should best practices become better practices or best-fit practices so they become molded, enhanced and understood by the organization and the people who will benefit from them? How do you enhance best practices for your projects? Do you think best practices are near perfect? Do you agree or disagree that extra effort should be applied to mold best practices? |
Grooming the Apprentice Project Manager
| How many of your project team members aspire to become project managers? Do you see promise in some of them for this role? How can you impart some of your knowledge and skills to help them be successful? There are elements of project management in everything that we do. It's your responsibility as the team leader or project manager to point this out to your team members and guide them to see the connections. A programmer might manage her time and communication, while also helping to develop a module, for example. A junior analyst may manage budget and scope while discussing the change request with the client. Show your team members how the tasks they are performing are also project management practices. This way, team members can appreciate that the work that they are doing is impacting the project as a whole. If team morale is often low, perhaps members don't see the significance of their work. You can help change their perspective by coaching them to view their contributions differently. Not all of your team members will appreciate your efforts. Some of them will feel that it's an interruption of their productive time or that you're meddling in the actual work being done. But by showing the team members how their tasks relate to project management, they will see that project management is present in everything that we do. And who knows? That skeptical team member could become your organization's next high performing project manager -- thanks to you. What do you think? Are project team members already performing some tasks of a project manager? How do you coach your team members to become good project managers? |
Managing Risks of Advanced Payments in Projects
Categories:
Risk Management
Categories: Risk Management
| In most projects, the issue of "advanced payment" vis-Ã -vis procurement management is very valuable. An advance payment is a prepaid expense from the client, paid to a vendor in advance for goods or services. The balance is paid after a successful project delivery. Advance payments are meant to provide financial aid to the vendor by providing initial funding for jump-starting the project. It also shows financial commitment and project approval from the client. Advanced payments are beneficial to the supplier, but are very risky for the client because the prepaid goods or services may not get delivered as planned. What if the vendor disappears with the advance payment? This would attack and distort the project's time and cost objectives. In order to mitigate this project risk, the project manager may request a sort of surety before supplying the required advance payment. Most project managers would settle for an Advance Payment Guarantee (APG) from a reputable bank. But banks often confuse the main goal of an APG on projects. Many times, the banks take care of operational risk while ignoring the aspirations of managing project risk. For instance, banks in Nigeria, where I work, may request a 100 percent cash backed prerequisite for an APG. The insistence of 100 percent cash backup connotes seizure of the funds, which are meant for the project (as provided by the client). It's good risk management on the bank's part. If the vendor flees with the advance payment, the bank would live up to its guarantees by taking the seized funds back to the client. To a discerning mind, this antagonizes the essence of project risk management. The funds from an advance payment are primarily meant to be an inflow into the project to mitigate the initial funding challenges of the project. But the vendor would be exposed to sourcing the same funds that had been provided by the client, which would delay the project. Any bank that is familiar with risk management should be willing to cater to the peculiar needs of the project objectives. There could be other ways of monitoring advance payment disbursement to the vendor as opposed to seizure of the entire funds while still expecting performance with the seized funds. What do you think? Do you use APGs on your projects? What issues do you face? How do you mitigate the risks of advance payments? Read more about risk management. Check out PMI's Communities of Practice for more information about Financial Services Industry and Project Risk Management. |
Working with Multigenerational Project Teams
| As a project management professional for 20 years, I've managed IT projects in a variety of industries and regions, including North America, Latin America and Europe. Most of the projects were regional or global, and the project teams included members from different nationalities, cultures and generations. Although complexity was a common denominator in these projects, it wasn't because of technology. It was because the people had what I call the "multi" factor: multinational, multicultural or multigenerational project teams. The "multi" factor plays an important role in projects, and project managers must be prepared to address team issues related to this phenomenon. I hope to do that here, starting with multigenerational teams. The multigenerational work force has created what I call the "21st Century Organizational Ecosystem." Many organizations may find themselves dealing with generational clashes between a 60-something program manager, a 40-something project manager, a 30-something project team leader and a 20-something project team member. This could just be one facet of this ecosystem. Project managers should understand the generational gaps in their project teams at the outset of a project. Identifying those gaps at the beginning enables the project manager to discern the preferred communication methods, interpretation of hierarchy and authority, as well as the perception of personal and work time. Leading a multigenerational project team can be like riding a roller coaster or a day at the beach. It depends on how quickly project managers can enhance their multigenerational behaviors and values to creating the synergy required to have a successful project team. How have you experienced the multigenerational factor in project teams? How has working with different generations affected your projects? See more posts about teams. |
The Employee as an Independent Consultant
Categories:
Career Development
Categories: Career Development
| This post was updated from its original version, published on 8 July 2011. I've been employed by the same multinational corporation for the past 27 years. About 15 years ago, I decided that I didn't like feeling like an employee, and decided to adopt the mindset of an independent consultant. Strictly speaking, I was and am still an employee. What changed was my mindset. I decided to think and behave like an independent consultant while continuing to be an employee of the same corporation. It's a nice arrangement. I treat my employer as if they were a client, my main client. With a couple of notable exceptions, they've given me steady work. Since I see myself as an independent project management consultant (even though I am really an employee), I have to think about marketing. If I don't keep the pipeline full, business could dry up. I make sure people know who I am, what my capabilities are and that I stand ready to help them. I do a lot of business development. I help people "on my own time" so they'll know what I can do for them should they have a need. I get to know who the decision makers are, who holds the budgets and who has influence. I keep myself sharp. Sometimes, my client/employer pays for my training and pays me when I take training. Sometimes they cover any travel expenses to take the training. Or, I may take training on my own time and expense to increase skills and my value proposition as an independent consultant. I interact with others in my profession apart from my client/employer. I belong to a professional organization (PMI) and volunteer with them as a speaker and writer. When I begin a new project, I approach it as a consultant, looking not only at how I can satisfy the immediate need, but also looking at the potential for follow-on work. When people I deal with are unpleasant or difficult to work with, I remind myself that they are my client, and will be paying me for my work. It helps keep things in perspective. I do the occasional "side job" for other clients, but only to the extent that it doesn't result in a conflict of interest. I don't think I would have the courage to make the career switch to truly be "independent." At least not yet. I have the utmost respect for those who really are independent. I understand that I don't face the same risks they do, which is why I have such respect for them. I've learned a lot from them and hope to learn more. But this works for me and seems to combine the best of both worlds. I have the satisfaction of doing work for people who seek me out as a professional, and doing so at a level of risk that I find tolerable. What do you think? Do you think working as an employee and behaving like a consultant would work for you? Why or why not? See more posts from Jim. Get more career help. |





