There are two schools of thoughts about whether PM should or should not be a SME as well. In a more broader terms, should PM have technical expertise on the subject of the project. How in-depth of knowledge about product should PM have? Historically, in IT PMs were developers who were promoted to PM roles. As a result, PMs were SMEs but not necessary business savvy people. Nova days, PMs are frequently business people and not technical experts. What will the future trend be for PMs? Which knowledge will be most important, technical expertise or business knowledge or both?
I'll be presenting at PMI London Chapter on 1st April 2019 at 6 PM
WHERE: University of Westminster (35 Marylebone Road, London, NW1 5LS)
You may be in your organization's C-Suite currently, or you may have upward mobility to be in the future. Regardless of where you are today, you are already empowered to be the Chief Executive Officer (CEO) for your Program (and/or Project). Join bestselling author Ms. Irene Didinsky "Author of the PMI endorsed 2017 released 'Practioner's Guide to Program Management' as she walks us through her ideology and framework for Program Management and how to mirror the impact, accountability and investment in your Program that a CEO has in their company.
If you're in London, please join.
Having led multiple projects, I almost always noticed sticking variations in project processes not only from company to company, but even from project to project in the same company, or even in the same department. Significant various in project processes results in variations in project delivery and inconsistent quality of project outcomes. It also impairs the team to jump right into project work, as the PM and the team need to learn the new project processes. I'm currently leading an effort to stand up a Delivery Center at my company. The Delivery Center will allow to shift from project oriented to product oriented delivery model. Along the way, I'm leading multiple initiatives to standardize processes. My approach is to assess current state and document it laying information in a way that it allows to compare and contract various approaches used by different projects. I then design a common and sometimes improved process. Sometimes this approach doesn't work as it requires to choose one process or the other, e.g. a software to house issues and risks. In the latter cases, I use pros and cons analysis and voting buttons to choose between two systems. What are your approaches to standardize project processes. Please share your thoughts.
Traditionally, software and other products are being delivered utilizing a project delivery approach. Under this approach, the product is being built for a particular customer. Even if it is a standardized product, it is than being rebuild to a degree or entirely (depending on the contract terms) for other customers. This approach allows for full customization of the product. However, it results lower product standardization, increase in waist and duplication of effort. Multiple teams work on resolving similar or the same issues. The product vary from project to project as some rules are a subject for interpretation.
Product delivery approach builds a standardized product that is being customized for each customer. This approach allows for higher efficiency and resources utilization, higher level of standardization, reductions in waist and duplication of efforts. This approach allows for a fully standardized product. Issues are found and fixed once. This approach allows to maximize team effort, improve efficiency and reduce waist. On the down side, some customization may not be possible.
What model do you use in your work? In your experience what are pros and cons of each.
Dear Friends and Colleagues happy holidays! All the best in 2019!