September 17, 2013
A Tribute to Ancient Engineers
It was the shore of south India. A great hero meditated on the ocean which stood between him and his destiny. His princess was trapped across the ocean, not too far. He had nothing but the company of his brother, an anthromorphic bear and an army of primates.
Legend says the sea rose up to greet the great hero and provide a solution. The key to crossing the ocean was already within the folds of the great army: the brothers Nala and Neela. Engineers who could construct a bridge to lead the army across.
The rest, is history.
Ramayana: The Epic
June 14, 2013
"But we've got day jobs!" or why Key Stakeholders are not your Project Team
Following Project Management (PM) best practices can be burdensome for non-project managers. One of the essential areas of PM is Human Resources. The key ideas being (1) find the right people according to the work to be done and (2) keep the wrong people out.
In a project I have been invited to, the project manager has chosen to be laissez-faire. Every knowledge area of the project is in everybody's heads and basic steps of project management are left to luck.
Whenever a requirement is brought up for creating solutions, only quick-fix solutions are proposed. Moreover, there is no plan to verify that the requirement was delivered. For instance, in the second meeting, the team followed a "cool suggestion" to print 100 photos of all employees, put them up on a wall with their names and departments. When I enquired about the goals of the activity, the activity was retro-justified as being (a) a spontaneous team building exercise for the project team and (b) will encourage collaboration across the organization.
There was no definition of how the efficacy of this work will be measured. How will we say that this investment in effort, time and money, however small, has delivered a real benefit. There are anecdotal reports of staff gathering around the picture wall and giggling. There was a written message, saying, it looked cool. The team complimented each other, patted each other's backs and dusted their hands and checked off a box. "We've achived a cool thing."
This is an issue. Even through the action is harmless, apparently, it is a violation of professional & social conduct, if the manager was a certified PM. Thankfully, that is not the case. So this ad-hoc team now becomes a good simulation of instinct-based project management.
The team is unwilling to define traceability of work and investment to objectives, except retroactively. The team is allergic to defining test and performance criteria for deliverables. Not because it lacks the know-how, but because the quick and dirty deliverables will actually need critical thinking and work to meet acceptability criteria. The excuse that is passed around like a smoking pipe: "We've got our day-jobs to do."
And that is where it all comes home. The failure to recognize that this ad-hoc team is actually Key Stakeholders not the Project Team. They want to give input and are too busy to execute the work needed with gravity. Nothing wrong with that. In fact, that is what makes them stakeholders. Once they help determine the work to be done, the appropriate talent should be sought out and assigned the work. This becomes too much for a non-project manager PM.
The question for me is how do I continue to offer value to this ad-hoc team, my initial expectations were "Project management consultant". Perhaps if the team is not interested in Scope, Time or Cost management (which removes the idea of a project completely) there is one area that could still help. Risk management. Maybe. Or I could simply define a sub-project and execute it using best practices.
This has been a rich experience so far. All the best to me.