quantmleap

In a post published almost two years ago I made the point that

…the apparent increase in the level of Agile adoption in recent years seems to link perfectly with the next generational change as we witness the gradual increase of Generation Y in the workforce. Gen Yers are perfectly engineered to adopt Agile. The team centric feature of the Agile approach is perfect for a generation who grew up in a collaborative, social media driven environment. Quick and short development cycles fit perfectly into the generational need to achieve and achieve quickly.

I also made the prediction that

Agile adoption will increase and with it the challenge for organizations to ensure this adoption is done for the right reasons. I wouldn’t be surprised if as a result of the growing exposure some changes will be incrementally added to the ‘methodology’ as this approach is maturing and entering center stage.

Fast forward two years and it is now a good time to take stock and gaze into the future.

One of the most noticeable phenomena we can witness today is the proliferation of Agile – as a concept – in almost every facet of the organization. The term ‘business agility’ is increasingly used to refer to adaptation of business processes, procedures and practices with a focus on delivering and achieving business value.

Adopting the Agile mindset also means  that organizations are now looking at the way they manage change with a view to enable faster response and adaptation to market and other organizational changes and remove or sidestep any organizational impediments that stand in the way of such responses.

The above mindset is also manifested in two undercurrents that seem to be catching an increased level of momentum:

1. Beyond Budgeting – a management model that enables people in the organization utilize their knowledge and experience and make decisions without the burden of excessive command and control mechanisms stifling their initiatives;
2. #NoEstimates – a movement to reduce the reliance on estimation, based on the assessment that most estimates are wrong and thus add little to no value to the organization.

It is worth noting that the Economist Intelligence Unit published a study in 2009, titled “Organizational Agility: How business can survive and thrive in turbulent times”, where it concluded that:

Nearly 90% of executives surveyed by the Economist Intelligence Unit believe that organisational agility is critical for business success. One-half of all chief executive officers (CEOs) and chief information officers (CIOs) polled agree that rapid decision-making and execution are not only important, but essential to a company’s competitive standing. Agility may also be linked to profitable growth: research conducted at the Massachusetts Institute of Technology (MIT) suggests that agile firms grow revenue 37% faster and generate 30% higher profits than non-agile companies.

Interestingly, the report also suggests that along side the above observations

1. “most companies admit they are not flexible enough to compete successfully” and further claim that
2. “Internal barriers stall agile change efforts“.

The observations brought earlier in this post seem to suggest that the path to clearing up these two issues is now well underway. The forces that have pushed the Agile revolution through the software development domain are now marching forth with a view to make similar revolutionary changes on a much grander scale. While there would still be resistance across boardrooms and executive teams it would be fair to suggest (along the famous line coined in one of the Star Trek movies) that “Resistance is futile”. The question now is not “IF” this mindset will prevail but rather “WHEN” it will get hold. The challenge for friends and foes is in collaborating in order to ensure that whatever transitional activities are taking place from the old to the new are done in a manner that ensures consistency and adaptability – controlled evolution vs forced revolution.

The future may already be here – it might just take a bit longer to see it.

Think about it!

Thanks to Kailash Awati for listening to my rant and helping me see the light at the end of the tunnel

Dr. Alex Hope has an interesting article titled “Project Management as if the World Matters…” where he reaches a number of conclusions that I find questionable.

The gist of the post is summarized upfront in the quote below:

[argue that]…most project managers are not yet integrating sustainability principles into project management practice, and that the profession needs to evolve to incorporate wider social, environmental and economic impacts. In fact I believe that we need to facilitate an evolutionary leap in the way in which we define, manage and communicate projects.

Alex uses a comparison of characteristics between project management and sustainable development and concludes that:

The definitions of a project and project management seem to be at odds with the definitions of sustainable development that aim to recognize the long-term nature of environmental or societal impacts arising from business activities.

While the post is well articulated I believe its core premises are wrong and I will attempt to explain why:

Project management is about meeting objectives and produce outputs. These outputs, depending on the circumstances in which they are produces, could be seen by society as contributing positively or negatively to its well being. For instance, a project that results in the erection of an energy producing wind turbine could  be embraced enthusiastically by green power advocates and rejected vehemently by bird and wild life advocates. The project itself, unless instructed to do so by its sponsors and owners, would not be interested in the opinions of either one of these groups, as its objective is not to meet their objectives but rather to meet the objectives set out for it as part of its charter and business case.

This leads to the following conclusion: If sustainability was to be a concern,  this concern would need to be the concern of those initiating  the project, the business or customer whose money is  invested in this initiative. Should they not be concerned about sustainability considerations, and provided that the project is operating within the legal and regulatory constraints relevant to its location, then not only does the project not need to concern itself with these issues, it should  not be addressing these matters because doing so will be an unethical thing to do in its own right.

There is another point worth mentioning here, this time about the apparent contradiction between the characteristics of project management and those of sustainable delivery. Let’s examine one example:

A project is characterized as being ‘short term oriented’ while a sustainable delivery is characterized as being ‘long term oriented’. IMHO, this fact can’t suggest any conclusion regarding this question. A short term project can be part of a large program or work, designated to take place over a number of years, with expected benefits, that once realized, contribute substantially and positively to sustainability objectives. There is nothing inherently suggestive in the fact that projects are short term to imply that they are sustainability unfriendly. They may or may not contribute to greater sustainability but, as outlined above, not due to their own innate characteristic but due to the terms and conditions imposed on them by those setting the business and policy direction for their implementation.

Want to achieve greater sustainability… deal with the people not the tools and methodologies they use.

Think about it!

The discussion around the #NoEstimates drive has raised all sorts of axillary arguments. One of these arguments is that there is virtually no difference between an Estimate and a Guess.

So just to set the record straight:

An estimate is a quantitative approximation based on previously observed data. The more relevant the data is, the higher will be the expectation that the approximation will be close to the true outcome (and the lower would be the uncertainty associated with this approximation).

A guesstimate is a quantitative approximation NOT based on previously observed data – and is rather based on gut-feel and a guess. Naturally this will attract a higher level of uncertainty.

You can argue that estimates are imperfect, are proven to be always wrong, etc, etc. At the end of the day though they are not guesses.

Think about it!

Came across the following tweet courtesy of Sue O’Connor

“@jeffweiner: Vintage social networking twitter.com/jeffweiner/sta…” Love it!

— sue o’connor (@Sue_OConnor) June 7, 2013

Ok, I know this is not related to project management (or anything else I’ve ranted about lately) but this is important. Google Reader is closing shop at the end of June 2013 and this has caused me a lot o grief as I use it daily to source and collect interesting reading material. Having explored a variety of other options I believe I now found the best substitute. It is called The Old Reader and once you import all your subscriptions from Google Reader you will (if you are like me) feel at home fairly quickly.

Give it a go.

There are many discussions out there evaluating the merits of having a PMP (or other) certifications.

The following post (see in this site),  titled “Should you get your project management professional (PMP) certification?” was brought to my attention and it provides a number of compelling reasons for an affirmative response:

1. A PMP certification makes your resume more attractive
2. PMP certified professionals earn higher salaries
3. PMP certification helps you learn a common language
4. A PMP can help you cash in on demand for project managers.

Do these reasons resonate with you?

Think about it!

The LiquidPlanner Blog has published the below Infographic which I am happy to share:

Thanks to Jussi Mononen I was introduced to the concept of Beyond Budgeting and found the following on YouTube. If you’r happy to entertain the idea that there are other ways – beyond the commonly accepted ones – to do things, then watch this video and see if it gets your wheels going.

I would love to hear what you think about it!

The word ‘Conspire’ according to Google can mean:

1. Make secret plans jointly to commit an unlawful or harmful act.
2. (of events or circumstances) Seem to be working together to bring about a particular result, typically to someone’s detriment.

It is not surprising then that when I was referred to a MindJet blog called Conspire, I approached the post with some care.

The post I was reviewing was titled “Hint, Hint: Project Management’s Dirty Little Secret” and some key gems are quoted verbatim below:

…project management still has one dirty little secret left: those deadlines you’re so worried about? They don’t really matter after all…

and, quoting from a statement made by a developer through the Harvard Business Review:

Everybody knows the schedule is a joke, and we pay no attention to it. It will be done when it’s done.

and finally:

Tasks rarely get done on time, anyway. If you’re already allowing extensions, you’ve already planned for this inevitability, so embrace it.

The notion that a project is a flexible endeavor where everything is up for grabs, that money is unlimited and schedule is only a recommendation, is simply wrong. I always challenge people who dare following this approach to put their money where their mouth is and honestly consider whether they would have been happy to commit their own hard-earned money on such a fishing expedition. The perception that due to uncertainty all responsibility is out the door is dead wrong, not to say immature and unprofessional.

Would you engage someone with such ideas as your preferred project manager?

Think about it!

I’ve attended a Meetup meeting in Melbourne last night which I found interesting. The purpose / objective of the meeting was described as follows:

Many Agile projects use velocity, burndown and burnup charts to measure the progress of the project. While these metrics measure the speed of delivery, they do not measure the business value it generates and this is where Earned Business Value (EBV) reporting is useful. Since the focus of Agile projects is on business value rather that conformance to requirements, the EBV reporting fits well within Agile projects and also sits squarely where the views of the customer, project manager and delivery team meet.

The essence of the EBV proposition was described as follows: While effort estimates for Stories are defined in relative terms (where as, for instance, a 5 points story is perceived to require five times more effort than a 1 point story); can a similar approach be used to ascribe Business Value to each story? This would mean that a business person, the Product Owner for example, would determine relative business value for each of the backlog stories (or features) and by doing so will enable a number of outcomes:

1. Assign relative priority to the order in which the stories need to developed (high priority BV stories over low priority BV stories)
2. Allow for constant scrutiny regarding the benefits of attending to the remaining stories that are of low value, versus allocating development resources to other projects where high priority stories might still be outstanding.

While this approach still needs some further elaboration it seems like something that would be worth while investigating and collaborating about. For instance, one of the questions I couldn’t quite put my head around is in relation to how would business value (being a relative and subjective assessment) be compared across different projects, especially when the people ascribing the business value are different people.

So, still work in progress but certainly worth thinking about it!