Portfolio Management

According to the standards of portfolio management by PMI, “A portfolio is a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives”[1]. Any organization has very well defined business goals and strategic objectives. The organizations devise strategies and create a vision for the members of the organization as a guideline to follow in order to fulfill the business goals and strategic objectives defined by the organization. The strategies and vision lay the foundation for quantifying a portfolio and the entities within a portfolio.

A portfolio on the organizational level may very well boil down to quantifiable items as projects & programs as it starts trickling down through the organization business units and into different driving teams. It is very important at this stage that all the different people involved with the subcategorization are aware of the vision and strategic goals of the organization, as well as the timeframes in which the goals should be met. Any deviation in the implementation of strategy at BU levels might either prolong or nullify the benefits being looked for by the organization.

The portfolio management needs to happen at the highest levels in the organization to make sure that no deviation from the established strategic goals happen. The focus of all the different programs within the portfolio is to realize the intended benefits, in the given time-frame to achieve the strategic objective of the organization. In traditional companies, most of the times, the organizational structure has an impact on the portfolio. The portfolio programs, market segments to target, introduction of new/updated products and/or services, etc. are quite deeply entrenched into the organization’s structure and capabilities. Most companies try to fit the portfolio into their existing infrastructure.

Ideally, the portfolio should be driving the organization structure and update the capabilities of the organization on a need basis. Digital transformation helps the organizations to decouple the portfolio from organization structure. Capability adjustment is done based on the project/program requirements according to the defined portfolio. Digital transformation gives more flexibility to portfolio managers to adjust the portfolio based on external factors and to align with a changing organization mission & vision if there is one.

The relationship between various components in the portfolio needs to be well-defined and maintained. Any addition or removal of components in a portfolio needs to be double-checked with regards to its relationship to other components so as have a minimal impact on other components and undergoing portfolio execution. Operations management, sponsors and stakeholders should be taken into confidence before any movement in the portfolio or subsidiary portfolio is done.

[1] – Project Management Institute (2018). The standard for portfolio management. Newtown Square, Pa: Project Management Institute, p.3.

Benefits Realization

I have been asking a lot of technocrats around in various verticals on whether they have been successfully tracking benefits realization in one or other format and making sure that they are constantly aligned and in sync with the organizational objectives, the most I get is glares and a few cheeky answers as to how they don’t get any “added/extra” benefit! Benefits realization management, defined in Benefits Realization Management: A practice guide, “BRM encompasses the standard methods and processes that an organization uses for identifying benefits, executing its benefits realization plans, and sustaining the realized benefits facilitated by portfolio, program, and project initiatives. BRM requires alignment with an organization’s strategy, a solid understanding of key principles, and techniques”[1].

Benefits realization in most product companies start and end at the business case development & analysis. Companies venturing into the service sector though has a different outlook and do have artifacts related to every business deal negotiation that more or less identifies benefits to both the supplier and the consumer. Most of the benefits detailed out in multiple artifacts are direct and tangible benefits such as a reduction in cost incurred, OPEX normalization, increase in market share, capability improvement, etc. Again, as I find it, no formal measurements are ever done for these benefits realization.

For example, if a project overruns its allocated budget, it is simply allocated a bit more or warped into another bigger project. If a deadline seems to be not feasible, it is simply moved to the next feasible date! No clear benefit realization revisits happen. In certain cases where the organization itself is driving important projects to realize its own organizational goals, the delays in project timelines seem to be accounted for by pushing in more money and more people to achieve the desired outcome.

In general, what I personally feel is that BRM as a process is not at all followed in most product organizations. Benefits register is rarely maintained and benefits themselves are having little mention outside of the business case documents and project charters. What’s your view?

[1] – Project Management Institute (2019). Benefits realization management : a practice guide. Newtown Square, Pennsylvania: Project Management Institute, pp.7.

Digital Transformation & Cross-Functional Teams

One of the important aspects of Digitial Transformation is the introduction of cross-functional teams. A cross-functional team is a group of people with different functional expertise working toward a common goal[1]. Cross-functional teams include people from various departments with different functional expertise working towards a common organizational goal. This teams also might have people from outside of the organization such as suppliers, key customers, etc.

The purpose of the cross-functional team is to facilitate innovation through creative collaboration leading to higher throughput and quick problem resolution. Another purpose of the cross-functional team is to break the silos that typically happen in big organizations and instead try to build bridges for communication. All the people in a cross-functional team have various levels of expertise so even if the posed problem is not solved, it can easily be taken to an “expert” by the team for doubt resolution and a probable way forward. All in all, cross-functional teams do lead to improved coordination across various functional areas.

Cross-functional teams are a necessity for an organization to introduce digital transformation and venture into the field of Digitalization. The most important part of breaking of the silos or creating fast throughput communication bridges between various operational areas in the organization is the key for succeeding in the process of digital transformation. In the Projectified with PMI podcast, “Digital transformation – What it takes”[2], Anand Swaminathan cites an example of the ING company which is one of the largest financial conglomerates, who created cross-functional cross-discipline teams to provide a customer with the full experience of ING products & services. They called such teams as tribes & squads who work towards providing the best possible solution to their customers.

One more example was cited for the medical field where hospitals reorganized the teams to deliver healthcare centered around patient needs thus optimizing the patient throughput and reducing patient wait times. I do agree to the benefits of having cross-functional and/or cross-disciplined teams providing for faster turn around times. But such teams can only provide for faster turn around times till the problems faced are generic and do not require any special/expert in-depth consideration.

When a customer, for instance, comes in with a very specific problem which needs deeper analysis from experts in the area for a proper resolution, cross-functional teams are way more inefficient at handling this kind of situations. An example can be a child who enters an ER complaining of chest pains. Or a customer who already has billions of dollars invested in funds and now wants to move them into crypto. Also, research-intensive tasks such as finding a new DNA sequencing algorithm or optimizing the frequency utilization for a given band will pose some great challenges to cross-functional teams which they will not be able to clear.

In general, any problem which has not been solved previously will be a difficult one for cross-functional teams to handle. Digital transformation has various levels of success depending on the industry type and the way external and internal stakeholders & customers interact with the eco-system. Personally, I see the cross-functional cross-disciplined teams as assembly pipelines[3](progressive assembly) in a broader sense. Of course, it does not mean that the cross-functional cross-disciplined teams work in a sequence without variations. What I mean to suggest is that the efficiency of the cross-functional cross-disciplined team is greatly enhanced by having the “semi-assembled parts” ready! As long as the teams are not going to invent a new “assembly part”, everything should go smoothly.

As I see it, the way these teams are successful is because most of the problems faced by external/internal customers are not new and have already been previously solved. The cross-functional cross-disciplined teams take advantage of the previous experience to provide a faster solution and in doing so add to the previous experience. So my take on the aspect is to regard cross-functional cross-disciplined teams as structural organizations that can reduce the organizational overhead as well as break the silos and increase cross-functional communication.

And it does not mean that specialized organizations and roles are not needed anymore. Specialized organizations and roles just do not solve the already solved problems and hence the increase in efficiency since 90% of the problems are being solved externally from the core/expert group. I have seen organizations deeply involved in research, for instance, taking the cross-functional team as buffered pools for doing systematic research. This has a negative effect on digital transformation hindering the actual output of such research focussed organizations.

Please do post comments as I would like to understand if this is a general sentiment across the industry.

[1] – Krajewski, L. J. and L. P. Ritzman. 2005. Operations Management: Processes and Value Chains. Pearson Education, Upper Saddle River.
[2] – Project Management Institute, Inc (2018). Digital Transformation: What It Takes | Projectified. [online] Pmi.org. Available at: https://www.pmi.org/learning/training-development/projectified-podcast/podcasts/digital-transformation-what-it-takes [Accessed 18 Sep. 2019].
[3] – Wikipedia Contributors (2019). Assembly line. [online] Wikipedia. Available at: https://en.wikipedia.org/wiki/Assembly_line [Accessed 27 Apr. 2019].

Project Benefits Management Plan

According to PMBOK, “The project benefits management plan is the document that describes how and when the benefits of the project will be delivered, and describes the mechanisms that should be in place to measure those benefits. A project benefit is defined as an outcome of actions, behaviors, products, services, or results that provide value to the sponsoring organization as well as to the project’s intended beneficiaries”[1].

This document is a living document and according to me, its life-cycle starts way before any business plan is laid out. Information exists for this but maybe not in a centralized place. Many factors such as business execution environment changes (evolution, devolution or revolution) and/or strategy, management and economy changes are the ones which trigger activities that generate a probably viable business sustenance/execution plan.

Formation of a project and/or group of projects/programs comes way later in the picture. Risks, assumptions, and timeframe for benefits realization are the most important key elements that shape a project and/or program. Investments and ROI of a business proposition play a very tangible role in idea generation which later based on other factors can lead to project ideas and/or planning of benefits realization.

Needs assessment and business case generation/analysis comes at a later stage after the investment model and ROI generation has been effectively strategized. All big companies including start-ups take this very effective approach to project initiation. In practice, I have seen the business case and project benefits plan going out of sync even though the strategic owners of both of them are more or less from the same organization. At times, both of them will be creatively used to influence a go-no-go decision on a project and/or make-buy decisions.

In general, if a project slips the implementation timeframes, the timeframes for benefits realization also slips. And at times, business case might make sense in a long term strategic perspective but the immediate benefits realization might get hampered and become invalid. Personally, I would prefer if the strategic owners of the business plan and benefits realization plan are in sync with the project sponsors. Project manager, in this case, is a mere executioner with very little control on the external factors. What is your view?

[1]  Project Management Institute (2017). A guide to the project management body of knowledge : (PMBOK guide). Newtown Square, Pa: Project Management Institute, p.33.

Project & People Management

Project management has been very much talked about and PMBOK is an excellent resource to get all the relevant information. I think people everywhere in public & private life do understand the value of project management. Simple tasks in everyday life (eg: go for an offsite meeting on Friday evening ;)) are looked upon as projects by parents. Everybody involved (husband, wife & children in this case) needs to be on the same page when it comes to execution.

In a professional project that I am involved with right now (automotive), the project initiation factors are manifold including “New Technology”, “Competitive Forces”, “Market Demand” & “Strategic opportunity” as well as “Business Need” to stay relevant in a slow-changing industry. The automotive industry by itself has been very innovative and has been incorporating new technologies as fast as it can. But the processing of artifacts in the industry has more or less been the same from the beginning.

Typical projects in the industry last for 15 years with about 5 years of development lead time, 5 years of shelf time and 5 years of support services. The SW projects, on the other hand, are not that long (typically the life of an SW is maxing 2-3 years) after which a new version or upgrade needs to be issued. The contradiction in the industry now is to get the people in the industry to understand SW methodology and to get the people in the SW to understand the automotive industry!

People working in their respective fields are excellent in their field of knowledge and very reluctant to change their way of thinking and/or processing information. If I take an example, fully autonomous vehicles will be running multi-core HW with a full-fledged POSIX compliant OS plus applications running on it. Now the SW for such a complex system needs to be updated. The size of updates is up in GigaBytes. So the downtime for automobile during servicing, production, etc. might increase if the old way of doing updates is not modernized. But doing this modernization will in effect change the whole process of procurement, production, and service in the industry.

In general, I find that people, especially in the automobile industry are unable to grasp the importance of changing the processes and philosophy to fit in with the needs and demand for modern-day technology. The project manager is more involved with doing people management in this particular project. Some of the tasks like:

  • Getting different teams to talk to each other
  • Promoting common vocabulary
  • Plugging in the core software into the electrical and mechanical engineering teams
  • Requirements management
  • Communications towards stakeholders including 3rd parties
  • Driving infrastructure changes related
  • Assigning ownership (especially because the old ways of attributing ownership is not applicable anymore)
  • Most importantly, changing the mindset of people

I personally do think that people management in this project is as important as project management if not more. Since a lot of things are new, people are afraid of executing tasks since they might end up on the wrong side of the door. People hence needs to be managed so that they feel more confident and more cozy with the changing environment. So according to me, it is not only the project that one needs to manage, but one also needs to manage all the multitude of people who are even remotely going to be affected by the product/services change that the project is driving. And this can be quite overwhelming especially because of cultural differences as well as the fear of failure. Plus there are no real guidelines here.