Get Agile and Trash Traditional Project Management

PMBOK and PMI have long focused on traditional project management techniques – developing work breakdown structures, linking tasks to build a network, estimating effort, assigning resources, levling, scheduling, forward passes, backward passes, slack etc. etc. etc. This stuff works, no doubt about it, but it works best for projects not many of us really work on in the corporate world.

Traditional project management requires that the practictioners and stakeholders have the right level of expert knowledge and understanding. For example to build a WBS to build a sky scraper, with sufficient detail to ensure all required and ancillary tasks are identified, requires someone who has built a skyscraper before, and probably a bunch of experts that know about construction, architecture, logistics, politics etc.

Many of us may never really work on such a project. In the corporate world, a lot of the projects you are faced with are implementing something new and unique. Even software development projects tend to be unique due to the speed of technology change. Building a WBS structure and spending a bunch of time upfront building a comprehensive task list may not be realistic, as tasks aren’t quite clear as to what needs to happen down the road.

Agile Project Management (also known as Agile Scrum Methodology) is an excellent choice for managing projects that have rapid time frames or unclear requirements. Under Agile, the methodology is very simple – communicate often, don’t let planning get in the way of doing, and give the experts the power, not the management.

A team would define a short period of time to execute on tasks, called a sprint – typically one to two weeks. The team spends time talking everyday to build the list of tasks to accomplish during the sprint. Within the team there are very clear roles of who is accountable for requirements and approval of work (the product owner) and those actually doing the work. All other stakeholders (managers, end users, political influencers) take non-speaking roles, requiring all communication through the product owner.

I would recommend that everyone spend a bit more time learning about Agile project managment – while considered a software development process, it is a great tool to have in your toolkit and readily adaptable to several project scenarios.

http://www.agilealliance.org/

 

 

 

Realizing the Business Case – where things fall apart

Last week we talked briefly about the need to close projects.
While I am sure we will be spending more time on this topic in future sessions,
I thought it would be worthwhile to provide some of my experiences / thoughts
on this subject.

Over several years of consulting, I have observed a repeated
behavior of not following through on measuring the business case post implementation at several of my client
firms. Several projects I have been on, in fact the majority have required a
business case. The business case typically outlines the financial, tangible
benefit the project will bring. Installing an automation tool? It will bring an
xx% reduction in FTE (labor) costs associated with that process. Developing a
new CRM? Look for top line growth of xx% six months after completion. In many
cases, the business case outlines savings or growth that will provide for a
favorable return or positive NPV within the organizations target timeframe
(usually 12 to 36 months).

Yet, at the completion of these projects, many of the clients are
left scratching their heads wondering if they in fact received their money’s
worth for the project. There are a number of factors that can lead to this, but
below are two takeaways I have observed from many clients:

1. Business case estimates are not impartial, empirical or
researched – in many organizations business cases are ‘gamed’ – estimation
models are subjective and typically developed by the parties with a vested
interest in performing the project. Furthermore the estimates provided are
rarely driven by statistical fact or equation based formula, but heuristic
estimations based on perfect world scenarios. Finally, firms typically do not
research what types of returns similar projects have provided for other firms
who have attempted them. All of these areas require some additional upfront
investment, but this can be far less than completing a project that doesn’t
meet its value

2. Failure to baseline – Many times, project business cases are
based on improvements in service from the current state, a faster time to
market, or improved uptime. Failure to accurately measure and baseline the
current service will invariably leave a project open to ‘pot shots’ from stake
holders post implementation. “This was way simpler before” or
“This seems slower than what we wanted” are difficult statements to
discredit and once uttered, can cement executive perception. When projects are
relying on service improvements as a basis for investment, before any ‘shovel
hits the dirt’ the project plan should include steps to create a set of agreed
to measurements that all stakeholders feel accurately and completely measure
the service, and those measurements should be taken from the ‘in place’ system,
with improvement targets set for project success.

Other problems include lack of funding to ensure the project can
measure success after the fact, undersized PMOs (where Project Managers
immediately are sucked into the ‘next big thing’ as soon as the project is in
production) and several others. I look forward to seeing what we discuss in
class down the road.