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.

Lean Startup (LS) method for product management

Startups should not implement the practices common in existing companies because they are not not smaller version of large companies. The LS movement is aimed to establish appropriate practices for startups which are different from what MBA graduates learn in business schools. Thanks to Steve Blank who has articulated the philosophies and principles in his web, videos, books and others. Continue reading

Lift-off

This post represents my own reflections on Diana Larsen’s book “Liftoff: Launching Agile Teams & Projects“.

Project chartering is well established project management practice. However, the stress in agile chartering is on the collaborative and carefully designed activities to create the charter. Project chartering is part of project liftoff.

A successful project liftoff can set it on the right orbit required to arrive at its destination. It is not a guarantee of success, however, it is a proactive risk mitigation to propel the project on the right orbit. Skipping the liftoff is a recipe for failure .

Liftoff is a session which should be carefully planned for to:

  1. Estimate required time for Liftoff session, participants, agenda, logistics.
  2. Distribute materials before the liftoff session.
  3. The pre work session is a group activity that is led by the product owner/sponsor to vet project idea, arrive at project purpose, estimate the budget, identify the product owner and enforce sponsor commitment.

The liftoff session to be successful must serve to:

  1. Create strong sense of ownership among participants on its outcomes.
  2. Sponsor demonstrates his commitment to the project.
  3. The session should be based on activities but those activities should be well designed to serve real world purpose of the project.
  4. Create charter for every team involved in the project.

Liftoff session activities can include retrospective to reconcile the team by having shared understanding on what happened in previous phases of the project or in other projects.

Liftoff can be used to improve the situation of existing projects. I see real world examples of canceled projects because of not meeting anticipated benefits. Those projects were set to navigate in wrong orbit. The project community who interacts directly with such failed projects concluded that the project is taking them to no where or to a destination they did not want.

An outcome of project liftoff is  the charter which should serve to have all project team and community agree on purpose, have alignment needed to achieve the purpose, and provide shared understanding on the context and boundaries of the project.

Chartering is a collaborative endeavor that focuses on the whole system and the interdependencies among all people involved in the project. Charter undergoes continuous improvement throughout the project, therefore, our aim in chartering session is to have a Good Enough For Now (GEFN) version of  the charter.

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

A Concordia waterfall project

For large projects, the size can be 50+ people working for 1.5 to 3 years, which is more than 100,000  man-hours/year. If the project is about to sink, new skills will be required which are not available in the project team.

It can be surprising how such entity which can have wealth of skills and resources are not capable to save the project. In fact the ship captain and crews will step aside (either voluntarily or forced)  and leave the helm for rescue consultants till the ship becomes ready for normal operation. Continue reading

Time-boxed Value Stream

For large organizations, projects are often characterized of being:

  • Involve people from various departments with separate reporting structure.
  • Involve contractors from multiple vendors.
  • Introduce technology which is unfamiliar to the employees.
  • General disagreement or even lack of appreciation of the project approach.
  • Multiple chiefs and puzzled doers.
  • Software development is sub-component of the project. Continue reading

Can we remove term project from software development?

My understanding that the term project in software development is at best confusing. The engineering team consists of all skills needed to produce increment of the software product. The term release is more indicative than “project” for the kind of work done by the engineering team. The release establishes the following:

  1. Release defined features.
  2. Sprint-wise stories forming the slicing of requirements in order to create the release features incrementally and often.
  3. Release tracking charts.
  4. Release creates a shippable client product while interim sprints are increments which are potentially shippable
  5. By end of the release we create plan for the next release.
  6. The release plan is the way to bring the product road-map to reality.
  7. The business value delivered to the client is measured by the overall business value of the features of the release features.
  8. The release plan has associated budget and estimated business value.
  9. Risk assessment was done at feature level and in totality constitute overall release risk.
  10. There is NO project manager. The LEGO guy at the right doesn’t lead this funny LEGO wagon. Instead there is facilitator who has no authority but capable to help the team to adopt the Agile principles.

The business people should understand that the team works according to its release plan and not to their project plan. This understanding should shift the organization from project paradigm to team paradigm. Sales people should create commitments based on the backlog and release plans per team.