Project manager’s dilemma

I worked with great project managers whom all work was centered on them. They treated team members with dignity, they worked long hours, track risks, follow-up actions to conclusion, address organizational impediments, be the single point of contact for the project, take responsibility for project failures instead of pointing to team members,……

The reality is that project manager (PM) constructs a temporary organization, during the project duration, to provide the needed discipline to get things done. Meaning, without this temporary organization, business accomplishments cannot be realized. The whole gamut of project management is founded to address this time tested fact.

Organization’s success becomes dependent on this temporary ‘virtual’ organization, which its CEO is the PM. But this quasi CEO has no authority, while he needs to constantly deal with impediments in the parent organization that stands in the project way. In other words, there is invisible contract between the organization and the project manager, whereas the latter secures his job in return of fill-in for the leaders. This makes the PM’s role one of the riskiest jobs in IT industry.

Why we need to have a PM to tell the organization that it needs to change its practices? For every PM I dealt with, they believed that organizational impediments are the main project’s threats. They are less worry about technology issues, solution complexity, process aspects, training, deadlines and other familiar risks. In many cases such organizational impediments cannot be communicated but rather the PM keeps and cannot even document in the project status or impediments log. The worst quickly happens, when the PM’s reason of existence becomes dependent on the existence of such impediments. Do you think a PM in this environment would have any interest to make such impediments visible?

Agile organizations have leadership at their foundation, which can further reduce the value-add of traditional PM. However, many of traditional PMs transcended to process consultants, enablers for team empowerment, professional facilitators, and other Lean/Agile roles.

Finally, strong PM and Agile/Lean are for me contradictory premises. The more an organization needs a PM, the higher the chance it is not ready or willing to change its long-time organizational impediments.

Vulnerability theory to build Agile teams

According to Brene Brown, Vulnerability is the birth place of Creativity, Innovation and Change. The rest of this blog is my own view on the implementation of Vulnerability in Agile teams.

Creativity is the ability of the team to create customer valued products.

Innovation is the ability of the team and product manager to come up with features which address the real pains of the customer and provide him gains which he hasn’t thought about. Continue reading

Queues understanding to improve productivity

I work with Agile cross-functional team who don’t meet Scrum prerequisites but still want to move toward Agile. I don’t have the authority or can sell the tenet to management to change their team set-up.

People in the team came from different departments and there is lack of understanding of queues and hand-offs. We are not waterfall, rather we are Lean concurrent parallel work in analysis, design, coding, testing and system test.

Continue reading

Lean for IT/Software.. Make knowledge explicit/2

This is the second post for implementing Lean in Knowledge Work based on Harvard Business Review article here, you can read my previous post about visualising waste here. When trying to make knowledge explicit, we should appreciate the following:

  • People are non-fungible. People differentiate themselves based on their character and ethics.
  • Skills are levelled: We will continue to have people of varied degree of competency in certain skill.
  • Having knowledge explicit will never replace people and their interactions. Continue reading

Lean for Knowledge Work

Agile methods promote experimentation to discover the unknown and desired product. Please see my post here.  Not all software or IT projects require experimentation as noted in the post. Harvard Business Review article here suggested that Lean philosophies are well applied to non experimental IT/Software  projects. Such projects will benefit from Lean approach in a way that can not be obtained from applying Agile methods. Continue reading

Managing Large Lean Software Projects

This post based on my reading of Henrik Kniberg’s book Lean from the Trenches. I am not going to write a detailed review on the book but rather I provide my own interpretations.

Maturity in using the tool

Either Scrum, Kanban or XP we should avoid getting obsessed by any one. Instead use them according to the situation. They can be helpful in providing guidelines but they can be tweaked wisely to the environment. Our approach for managing development or project should be composite rather biased to specific method or technique. Continue reading