Agility and Project Leadership

This very interesting and profund post by Douglas Rushkoff calls into question our current fixation of creating more jobs.  As he states:

"We're living in an economy where productivity is no longer the goal, employment is. That's because, on a very fundamental level, we have pretty much everything we need... Our problem is not that we don't have enough stuff -- it's that we don't have enough ways for people to work and prove that they deserve this stuff."

With Obama ready to get approval for the jobs package and America and most of the rest of the world in an economic and jobless slump, this is a very provacative statement to make in light of our current situation.  Nevertheless, the lingering economic slump and ability of corporations to maintain and in many cases, increase profits despite high unemployement does require us to call into question the current viability of our economic systems and the foundations of work, employment and careers.  Add to this the rapid technological and productivity changes of the past decade, and this only accelerates the need for self reflection and re-examination of our careers.

While I'm not completely sold on Rushkoff's proposal for a more colloborative and community based economic system that uses a form of barter and/or local currency to exchange intellectual goods while our basic needs get met, I do agree that the concept of having a "job" is becoming increasingly obsolete.

For readers of this site who are project managers, is our own profession becoming obsolete as well?  I would answer "it all depends".

I think if your a "true" project manager, which by that I mean a person who truly leads and manages a team, has breath and depth of knowledge to be able to make decisions on the direction of tasks and work, and can effectively communicate to teams and stakeholders, then you will always be valuable.  But if your just a project scheduler, status reporter or task tracker, then you will likely become obsolete by technology and business process productivity improvements.

Furthermore, you will really need to be "agile".  I'm not just talking about becoming a ScrumMaster and doing Scrum, but really have the ability to adapt, evolve and reinvent your skills and management methods to technological, economical and social change.  This is big stuff.  I really see project management skills as being key to future survival, as it is not out of the question to foresee a future where we're all free agents, who bid on projects and have to form teams, draw plans, and execute projects with high quality deliverables quickly, then disband and move on to the next project.  This is how movie studios have been delivering movies for quite some time, and it would be quite a social and economic change for everyone to be working this way.

I think we're at the starting point of a signficant change in how we work and deliver projects and you will either be thrilled by it or scared to death.  I'd chose the former.

In traditional project management, it is typically recommended that you conduct a project handover (and/or ceremony) and close the project.  This is typically done with a project closure document.  And though much of the emphasis is on planning your project thoroughly, mitigating the risk and issues and executing the project to its successful outcome, the closing aspect of the project is not mentioned enough in the industry, nor is it done well or at all.

Much is discussed about facilitating self-organizing teams in Agile/Scrum.  In my article on the Japanese origins of Scrum, Takeuchi and Nonaka who originated and inspired the Scrum movement, discussed the aspects of self-organization that leads teams to create their own unique rhythm, as they are forced to synchronize their work and pace in order to reach project timelines. 

But the question as to how to maintain peak performance of these teams is not addressed by the framework.  This is not surprising since Scrum is a light weight framework that leaves it up to the implementor to implement.  Fortunately, there has been a movement by Tony Schwartz called The Energy Project, which addresses identifying and managing our natural bio-rythms and fluctuating energy levels to achieve peak performance.

According to the site, based on a 2008 Towers Perrin Global Workforce Study of 90,000 employees across 18 countries, only 20 percent of them – 1 out of every five – feel fully engaged at work. Forty percent are actively disengaged.  Demand is exceeding our capacity to match supply.  The ethic of "more, bigger, faster" exacts a series of silent but pernicious costs at work, undermining our energy, focus, creativity, and passion.  Nearly 75 percent of employees around the world feel disengaged at work every day, according to the Energy Project initiative.

This issue should be of no surprise to many of the project managers and ScrumMasters out there trying to manage and motivate burned out teams, within a corporate environment of slashed budgets, relentless pace of work and a looming fear of unemployment.

The idea is that by integrating multidisciplinary findings from the science of high performance, we can identify and manage the neglected four core needs that energize great performance: sustainability (physical); security (emotional); self-expression (mental); and significance (spiritual).  Rather than running like computers at high speeds for long periods, we're at our best when we pulse rhythmically between expending and regularly renewing energy across each of our four needs. 

At the individual level, it explains how we can build specific rituals into our daily schedules to balance intense effort with regular renewal.  To offset emotionally draining experiences with practices that fuel endurance and move between a narrow focus on urgent demands towards more strategic and creative thinking.  Ultimately, it seeks to balance a short-term focus on immediate results with a values-based commitment that deliver real business value and organizational harmony. 

The site kind of overhypes the idea, but the main ideas behind identifying, managing and facilitating your teams ability to self-organize according to core energy levels at the physical, emotional, mental and spirititual levels is a powerful idea that should be explored more.

Having been involved with large infrastructure projects, both in IT and construction, it is almost always the goal to get vendors to settle on a fixed priced contracts.  The advantage of using this type of contract is the reduced level of work required by the buyer to manage the contract. The buyer will know the price being charged and the incentive lies with the seller to control costs. 

The two things to closely monitor is to ensure the work outlined in the SOW is actually being completed per the contract and the other is control change requests, which are typically negotiated away by the vendor to secure the contract but used to get back the profits lost due to it.  I have personally been involved with projects that had out of control change requests that resulted in projects being way over budget and delayed.  Though I don't have the statistics on hand, I'm certain many of the major project failures were due to the inability to manage changes in fixed price contracts, especially in the government sector.

Agile/Scrum does not have much literature on integrating procurement management with Agile/Scrum since most of these kinds of projects are done with co-located, in-house teams, though I did find this post from Jeff Sutherland that outlines a "money for nothing" approach, which is a hybrid fix price contract that includes time and materials for changes.  Here's a summary:

• Insert Money for Nothing clause in fixed price contract.
  • Only operational if customer follows Scrum rules
  • Mutually agreed estimates for all work items
  • Otherwise contract reverts to time and materials
• Customer determines ROI cutoff where implementation of the next feature costs more than the value of the feature
• Supplier allows termination of contract at any time for 20% of remaining contract value
• Supplier assumes risk of late delivery of mutually agreed deliverables

I've only previewed the presentation by Jeff Sutherland and plan to review it in depth, but some issues that come to mind for me immediately is to ensure the stakeholders understand that this is fixed in price, but not in price and scope and that changes can be added giving them flexibility, but to do so requires the removal of other features.  Another is the involvement of the Product Owner, since he/she is the one who works with the customer to obtain requirements that will add business value for the customer.  That person will have to buy off and fully understand the impacts of this approach to make it successful.

Have any of you out there adopted a similar approach?  I'd be very interested to know!

An article in the July 2011 issue of the Harvard Business Review, discuss the idea that we are embarking to an "Age of Hyperspecialization".  Here's a video interview with one of the authors Tom Malone:

In a nutshell, due to communication technologies and increasing reliance on knowledge based work, we are entering into an age where "much of the prosperity our world now enjoys comes from the productivity gains of dividing work into ever smaller tasks performed by ever more specialized workers... We are entering an era of hyperspecialization—a very different, and not yet widely understood, world of work".

You can read the article for the details, but the result of this article was highly polarized comments from readers on the HBR site as to the dehumanizing and repetitive drudgery of micro segmented tasks done by dispersed teams all around the world, with the added insult of having to complete with these individuals on price.

The authors do acknowledge the dangers of this trend and the abuses that could result.  I can't help but to mostly agree that this type of work will become more prevalent as the technologies that allow hyper-connectivity get better and better.  As the authors acknowledge, the best way to survive and thrive in this new work world will be to sell your hyperspeciaized skills as a portfolio of skills and to diversify your areas of expertise so that you are better equiped to adjust to market conditions.

The biggest impacts and implications of this movement would be the project managers who are tasked with tracking and putting together and delivering all these micro tasks into a workable, integrated solution.

This will force project managers to master a new set of skills (Some of these discussed in the article/video with additions and focus on PM): 

1. Rethink scope and requirements design
2. Divide work into assignable micro tasks (a WBS on steroids!)
3. Recruit and assign specialized workers to perform them
4. Have a hyper-connected, social media like communication plan
5. Control for acceptable quality
6. Integrating the many pieces into a whole solution

With our increasing need for adaptability and agility, this will require an agile mega-generalist project manager or Super-ScrumMaster.  This person will have to manage globally dispersed, self-organizing teams (they would have to be self organizing as it would be impossible to track and understand all those hyper-specialized tasks!), manage and maintain real-time, twitter like status updates and meetings throughout global time zones, then ensure all those micro pieces get put back together into a workable deliverable.  Iterations would have to be micro time boxed sprints (events and changes in this situation could be in the seconds).

If this scenario sounds unreal and maybe even comical, consider how much our world has changed in just the last decade in terms of the explosion of information and communication options brought about by technology and the accelerated changes that will take place in the coming years and the scenario is not all that unrealistic.

My feeling though is people who can truly be the agile mega-generalist project managers as outlined above, will be the leaders of this age.