A successful project requires a combination of technical and managerial activities at every stage to jointly deliver the final result and its benefits.
If you have high levels of maturity in project management without the equivalent technical knowledge, your project is doomed to deliver a poor solution. On the other hand, when you have best-in-class technical knowledge without project management maturity, your project is also doomed to be inefficient and maybe even inefficacious.
Many organizations have already developed competency models to encompass technical and managerial aspects of projects, describing overlapping areas and highlighting essential project management and systems engineering foundations of successful projects.
Consider the U.S.’ National Aeronautics and Space Administration’s (NASA) competency model, which “outlines distinct competency areas for project managers and systems engineers, as well as shared competencies that encompass both disciplines.”
Examples of defined project management competencies include:
Examples of defined system engineer competencies include:
Examples of shared competencies include:
You might be asking yourself what does NASA have to do with your own daily projects? Most of us are working in projects and programs far simpler than building space systems. However, my objective here is to call attention to the best in class so that we can contextualize and tailor their model to our own reality.
Of course, in order to achieve a proper balance in your projects, thoughtful tailoring is essential. Take the International Council on Systems Engineering’s handbook, A Guide for System Life Cycle Processes and Activities:
“On smaller projects, where the span of required communications is small (few people and short project life cycle) and the cost of rework is low, Systems Engineering activities can be conducted very informally (and thus at low cost). On larger projects, where the cost of failure or rework is high, increased formality can significantly help in achieving project opportunities and in mitigating project risk.”
Even small and medium projects can benefit a lot from the proper combination of project management and systems engineering. Systems engineering is helpful not only in developing complex products and services, such as a spaceship or an air traffic control system, but also in less sophisticated products such as a bicycle or an alarm system. In fact, systems engineering is even helpful when you are designing your new house.
What product development approaches are you using today? Please share your thoughts in the comments below.
by Ramiro Rodrigues
Years ago, I was invited to speak on project management trends to a group of entrepreneurs and businesspeople from small and medium-sized companies. When the subject of knowledge management in a project setting came up, I asked if people agreed that it was important for companies to retain the knowledge acquired for future projects. As expected, there was unanimous agreement.
I then asked people if they had already implemented some kind of system for lessons learned within their company. Only 15 percent of participants raised their hands.
This reflects a common corporate weakness.
Civil, architectural, marketing, research and development, and IT projects, among others, deliver products that rely on the intelligence and experience of those working on them. For these segments, the maintenance of this knowledge, or intellectual capital, offers a competitive advantage. After all, it’s this intellectual capital that allows the recurrence of new business transactions.
Imagine the case of a Brazilian construction company that has been awarded a contract for work in the Middle East. Geography, labor legislation and culture are complete unknowns for the company. The project is expected to experience a high number of challenges and errors. Even so, the project will be delivered. Now imagine that, years after the completion of that project, the same construction company is awarded another contract of similar size in a neighboring country in the region. Even though every project is unique, the knowledge acquired in the first project has immense financial value in helping avoid the same mistakes.
What we witness today is that the knowledgable worker is highly valuable. Imagine that, between the construction company's first and second project, its key leaders leave the company. If the organization has not implemented some kind of mechanism to retain the knowledge acquired during the first project, all the errors (and financial losses) that marked it are highly likely to be repeated in the second project.
And this, in some cases, can be fatal for the survival of the company.
This brings us to a corporate paradox. Most executives are likely to agree that it’s important to develop some kind of knowledge transfer structure. But at the same time, there is clear lethargy in freeing up resources to implement knowledge management systems for projects.
Not that it's simple — initiating any knowledge management process is inherently difficult. There is veiled resistance among workers to explain the knowledge acquired during projects. Either they don’t agree with its importance, find the process annoying or even fear it will make them less essential.
Leaders have to overcome this resistance. Neglecting the issue can put them at risk of being exposed to market volatility.
What challenges have you encountered with knowledge management? How do you make it work within your organization?
By Ramiro Rodrigues
I have heard arguments both for and against the effectiveness of corporations using standardized project management methodologies.
In general, a project management methodology should clarify which methods — steps, activities, gadgets and tools — can be used to reach a goal. And since a project is made up of a set of processes, each with their suggested methods or best practices, they are usually given the name of methodology.
The Arguments For
The fervent proponents of project management methodologies contend that there is a need for the implementing organization to establish an identity, which its clients will see. They believe that the methodology enhances the standardization of the particular strengths of the services offered.
According to them, a project originating from a corporation with a specific work methodology tends to have more predictable services and products, which decreases the interference of human factors associated with the individuals who lead the project. It also allows for greater clarity and understanding for the stakeholders with regard to what is to be expected at each moment.
Finally, they maintain, that a methodology enables a virtuous cycle of continuous improvement and development with regard to project management in an organization.
The Arguments Against
Opponents assert that methodologies often require disproportionate documentation efforts that do not add value. For them, methodologies are bureaucratic "machines" that increase their costs and stress levels, thus taking the focus away from the expected results.
There is no single solution to this issue. It is common knowledge that each organization must develop its own project management methodology in order to find the best set of methods.
Therefore, it is suggested that organizations wishing to improve should always consider whether the proposed methodology:
This latter issue, together with the need for resource optimization and a drop in the learning curve, has led corporations to search for alternatives — such as agile methods and using Canvas in project management.
However, this objectivity "line" should not be stretched too far. There’s a risk that while searching for leaner processes some aspects related to the optimal handling of a project may become too superficial. That could ultimately compromise the quality of project deliveries and the image of the implementing organization.
Therefore, there is no one perfect solution. Each market segment, project size and organizational culture should be carefully considered in order to find the best way to implement a project management methodology.
The Secrets to Business Transformation Success
In the world of business transformation, there is usually a lot of enthusiasm surrounding the start of the transformation among the team.
But it quickly gets crazy and stressful thanks to tenders for third parties, recruitment, preparation for executives’ meetings, changes, wish lists, vague strategies and aggressive key performance indicator promises already made to the board.
Typically, the transformation team has a list of to-dos and we go running around building the empire around achieving them—and off goes the train.
Some of the pitfalls that transformation teams fall into are:
Assume success: Business transformation is usually about a list of changes we make to the business—whether with systems, people, processes, strategy, or all of these. We build the portfolio, write the briefs for our third parties, start the projects and setup the meetings and steering committees.
We plan our work with success in mind. But what if that doesn’t happen?
When we don’t account for failure it means we don’t really have the recovery mechanism in place both at the human and team level and at the tactical level.
That leads us to the second pitfall.
Inability to stop and reflect: In transformation, there is a lot at stake. That means a lot can go wrong quickly—and the trust that the transformation team once had can be put to the test.
Because there are a lot of moving parts—and what you knew at a point in time may not be as valid or as accurate as it is at a later point—time to reflect and adjust course is essential.
At the end of the day, these teams work for their customers and when the customer needs change, so should the direction and the approach that the team takes.
Can’t or won’t say “no”: In successful and strong transformation teams, the ability to say “no” is crucial. That does not mean rejecting business requests, but rather working to prioritize and justify why things can or can’t be done.
Not understanding the capacity available can put the transformation team at risk. Senior managers and executives often look for a sounding board and an independent review of what might be possible. Don’t be shy to speak your mind and seek to understand and learn.
Transformation is about saying “no” as much as it is about saying, “Yes, we can.” It’s important to keep the organization honest to its true ability to implement change and work together with your customers to create something that works.
And finally, during a transformation it’s important to stay humble and always seek to learn. Don’t let your ego stand between you and a successful business transformation. But that’s another topic for another day.
A Checklist for Shared Outcomes
Education and Training,
Human Aspects of PM,
Categories: Benefits Realization, Best Practices, Career Help, Change Management, Communication, Communication, Complexity, Education and Training, Ethics, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Leadership, Leadership, Lessons Learned, Mentoring, PMOs, Portfolio Management, Procurement, Program Management, Project Delivery, Project Failure, Project Planning, Roundtable, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
I was recently assigned to transform a procurement team into one that managed outsourcing partnerships. I realized the team was very disengaged, leaving the strategy up to me to define. There was no buy-in. The team and the partnerships were sure to fail.
But I was determined to make the team successful. For me, this meant it would be accountable for managing thriving partnerships and delivering superior outcomes.
To get things back on track, I had to first get alignment on goals. Setting shared goals can help to shape collaborative and accountable teams that produce desired outcomes.
Establishing goal alignment can be a difficult leadership challenge; however, leaders must gather the needs of all stakeholders and analyze their importance to achieve the desired organization outcome.
I often use this checklist to tackle this challenge:
I used this checklist during the procurement team project and it helped to reset and reinvigorate the team. Once we aligned around shared goals, team collaboration increased and the organization started to achieve the targeted business benefits.
If you’ve used a checklist like this before, where have you stumbled and how did you turn it around?