Jump to Content/Skip Navigation

Arras People Project Management Newsletter


Agile project management? Or is it agile project management? Method or philosophy? SCRUM or DSDM Atern? And can someone tell me which one the APM Group's certification is tailored after?

These are some of the questions we've been asking about Agile from the project management community. There's plenty of confusion about what Agile means to practitioners in project management - just take a look yourself by performing a Google search!

We got really interested in March 2011 when the UK Government launched its new ICT strategy mandating all projects become smaller in scope and more Agile in method. Was it just a new buzzword for government project departments? Can the PRINCE2 ingrained ways of the ICT personnel translate easily to an Agile way? And again - which kind of Agile method is the Cabinet Office talking about, anyway?

We've enlisted the help of the Agile guru Keith Richards, who lays out for project managers what Agile can do, what it can't do, and also tackle that "method or philosophy" question. Our next author is Arras' John Thorpe, who tackles that same question and also applies the emergency brake to what sometimes feels like a runaway train bound for widespread Agile adoption without a true understanding of what we're getting ourselves into. Finally, Dan Strayer talked to Agile's advocates (agilistas and PMs), sorting through the benefits Agile can bring to certain projects while also getting a better appreciation for how Agile PM can be applied improperly. We also take a look at the professional bodies response to Agile and project management with courses and accreditations.

SPECIAL NOTES: Tipoffs is now available in podcast form for all of our audio fans keen on learning the ins and outs on project management, programme management and recruitment in the PPM world. The October podcast is now available. Click here to learn more about our podcasts and subscribe to our regular feed, or here to download us on iTunes. For the on-the-go, instantaneous information public, Project Management Tipoffs and Arras People are ready for you.

Would you like to advertise in the next issue of Project Management Tipoffs? We publish on the third Thursday of every month, and would like to have all advertising data (images, click-through links, invoices) taken care of the week before release. Contact us, check our running schedule and our advertising guidelines today.

Agile: What It Is, What It Isn't

Words: Keith Richards

In 2001 the term 'agile' was created to represent a family of lightweight approaches to software development. Over a decade later agile is now mainstream and is changing the way organisations deliver benefit to their customers whether this involves I.T. or not.

However, the growth of agile and how it sits with respect to traditional project management approaches such as PRINCE2 and PMI is not straight-forward. There is a huge amount of hype and confusion around what agile does and how it does it. The parallels to the snake oil salesmen of the mid-west in the 1800s can be found with promises of 'twice as much in half the time'.

Agile's application within a corporation's many different departments creates a hierarchy into how it is best utilised.

What are the origins of the hype?

Agile has its heritage in I.T. where it was generally used on a small scale, in environments where an existing software product already existed. There were many local successes and the idea of working with backlogs and to-do lists in regular timeboxes or sprints reaped rewards and created the spread of people using agile. In the UK this was epitomised by the use of methods such as SCRUM, XP (eXtreme Programming) and DSDM (Dynamic Systems Development Method).


Where has the confusion come from?

In a similar way to a child growing up, agile had challenges as it faced new situations.

The challenges it faced came in three areas:

  • Firstly, nearly all agile is being practised in what are called 'product' environments where something already exists and it needs enhancing or modifying. The idea of using agile in a 'project' environment is frequently ignored.
  • Secondly, nearly all of the agile debate is focused on I.T. solution delivery – the concept that this delivery is taking place in a wider context and needs to sit in a strategically-focussed business context is often overlooked.  What about when there is no I.T. element of a business change?
  • Thirdly, a lot of agile techniques do not work when they are scaled up into a larger context.

The leading thinkers in the agile arena have addressed this, but most people have not.

What is agile – is it a method or a philosophy?

Agile is a philosophy, a mindset.

In order to get the most out of agile, it is important to understand what is really meant by the term 'agile'. It is a very broad term and covers many things ranging from philosophical aspects, such as collaboration and self-organising, to more technical aspects such as the concept of writing requirements in the form of 'user stores' or using 'low-tech' burndown charts to show detailed progress.

Combing Agile and Project Management for the benefit of the project's best possible delivery gives you the best of all worlds.

This broad church of ideas and concepts is further heightened by the use of automated test-driven development (TDD) and continuous integration (CI) in the software domain.

But it doesn't stop there, as companies are taking the agile philosophy far beyond I.T. as they look to become agile at the programme, portfolio and even organisational level.

This great flexibility and opportunity for agile brings with it a burden in that it is a coat of very many colours and; as a whole it looks good, but people struggle to understand what makes up the parts.

A good example of this is that burndown charts, user stories, estimation games, MoSCoW prioritisation, pair programming and so on are seen as ‘being agile’, but they are in fact just a series of popular techniques. They can be used on a PRINCE2 project right now!

This causes confusion as many people see things as a straight choice between traditional project management or agile. Often this is peddled as a choice between 'the waterfall approach' or 'agile'. However, in these two widely held beliefs there are in fact two huge misconceptions:

  • The first misconception is that agile is an holistic approach to managing projects when in fact it is largely a set of product delivery techniques

  • The second misconception is that traditional project management approaches (e.g. PRINCE2) mandate a waterfall approach, when in fact they don't

Is agile, therefore, of only limited use?

As agile has come of age and grown past the Agile Manifesto launched in 2001, many people and companies have realised that it works on more than in just small-scale I.T. context.

Agile can be used anywhere and this is why it may well be the next big thing. It challenges a lot of traditional thinking but to get it to work you need to understand what it does, how it does it and why. When you address these points you can then address the three areas previously mentioned where agile is being misunderstood.

The dawning of an irony

The pioneers in the agile marketplace have realised that there is something of an irony in how to take agile to the next level. This is often called ‘corporate strength agile’ or ‘agile with rigour’ as opposed to ‘fragile agile’. This irony involves embracing some of the basics of traditional approaches to project management and integrating them with the agile ethos. What you create is the best of both worlds...keep some of the project management basics (e.g. up-front work, project management, governance, etc) and let the agile techniques do what they do best (e.g. respond to change, focus on time, build incrementally, etc).

No need to replace the likes of PRINCE2 and PMI. No need to reinvent the wheel. However, there is a need to bring the agile ethos into play and this is where the more scalable robust agile approaches such as DSDM and AgilePM come into their own.

Agile suggests flexibility, but that doesn't mean its introduction won't be met with some confusion from project team members as to how it can be best utilised.

Solving the problem – where to start

One key factor in getting agile to work on a larger scale and in environments needing stricter governance (e.g. when compliance is involved) is to realise that nearly all things agile operate at the ‘solution delivery’ level; therefore, how do we handle the ‘stuff’ that sits above this? An organisation can start to make quick progress when it realises that a lot of agile was never meant to work at the project management level let alone the project governance level.

But changes do need to be made at the project management and governance level. Agile may deliver a solution that is deliberately less than 100% and it will enable detailed change to be handled with less formality. It also eschews the need for detailed specification at the outset allowing understanding to evolve as the work progresses. Even the drafting of a business case is created in a slightly different way.

These differences are more than nuances and therefore it is imperative that senior management understand the reasons for using agile and the impact it will have. The key to success is bringing in agile as a managed change to a way an organisation works and not let it just happen or, worst of all, let it spread virally.

What if you are a project manager - what should you do?

It is important that everyone realises that this is not a case of a new broom sweeping out all of the traditional experience and the body of knowledge that has been built up over the decades. However, it is important for any individual to stay ‘current‘ with their skill set and adapt to the challenging times that many people are currently facing.

Therefore any project manager with any level of experience needs to shop wisely as they look at the various options to do with agile training and accreditations.

It is best to look at the bigger agile picture and realise that institutions like APMG, PMI and IfG (Institute for Government) are all seeing a big shift to large scale agile project management with or without an I.T. element. This is a significant step up from learning various agile techniques, most of which do not relate to the project management layer which sits above the solution-delivery layer where agile has come of age.

Do not confuse solution delivery with project management and don’t confuse team leading with project management, either!

Final thought

Agile is not the new PRINCE2; it is not even 'new'! It is, however, here to stay for a long while and it will be judged on how well it is adopted, implemented and practiced. In today’s economic climate those organisations and individuals who get it right will reap the rewards. Those that don't, won't!

"Agile Organisation" image courtesy Keith Richards Consulting

Keith Richards is the founder and managing director of Keith Richards Consultants (KRC). He has over 30 years experience in I.T. and project management and is also a director of the DSDM Consortium. In 2007 Keith led the team that created the latest version of DSDM. An accredited DSDM Practitioner and Trainer, PRINCE2 Practitioner and an IAF Accredited Facilitator, Keith has worked across all industry sectors and has been involved with a wide range of clients from SMEs to large government organisations. Specialising in the leading edge approach of combining DSDM with PRINCE2, Keith is the author of the book 'Agile Project Management' (published by TSO). Keith was recognised earlier this month as the "Most Valuable Agile Player UK" at the annual Agile Awards in London.

Let’s Be Agile Together!

Words: John Thorpe

As a project manager of many years experience, working both pan sector and discipline, whilst using many different flavours of methodology I have to admit that I am still struggling to position the "Agile" movement in terms of delivering projects.

Anyone's constitution is open to amendment. So, too, should be a so-called "method" of managing your projects to maximum effective delivery.

Coming from a manufacturing background I have exposure to Lean (make to stock) and Agile (make to order) and TOC[1] in terms of delivering products. As I remember it, these were always positioned as "philosophies" which an organisation could choose to embrace.

Having made their choice to follow a certain path, they then embarked on a top-down implementation of that philosophy, part of which was choosing and implementing methods or tools. Failure to embrace the philosophy would ultimately undermine the whole initiative and lead to a "bastardized" or "cherry picked" solution which "worked" (hopefully) for the organisation.

Moving forward into my years in Professional Services I began delivering Projects, using a wide range of methods and tools. My employing organisation had a methodology for project delivery, which changed and evolved over the years as our knowledge base increased; that base accounted for not only our own learning, but those of the wider project management community. We were not fussy - best practice worked for us and we would happily take from PMBoK, Prince or whatever came along that could increase our capability to deliver successful projects and programmes. Working with external clients and third-party suppliers we also had to be flexible as they often had their own project methodology into which we had to dovetail in order to ensure good relationships and a successful delivery. The key elements of our approach were:

  • We developed a flexible delivery framework which allowed for reporting and control.
  • It was never positioned as a philosophy.
  • The project managers were taught to be agile[2]; focussed on delivering the project, not the process. 
  • The "build it" phase of the framework was agnostic to the specifics of tools or methods which could be applied so it was equally applicable for a software project (RAD, JAD, SDLC, Waterfall) as it was a business change initiative.

One of the toughest phases of any new project was initiation, which in our case meant bidding or pre-sales. Here we had to build an understanding of the clients' requirements so that we could propose a deliverable (Features), the price we would wish to charge (Cost) and the anticipated delivery date (Time) whilst agreeing any desired Quality metrics. This was created with known uncertainties, assumptions and identified risks which were all factored into the proposal and associated contract. Whether time and materials or fixed price, variation (Change) was probably the only certainty, and as such we developed Risk and Issue Management (RIM) and Change Control procedures which managed this for all parties involved.

So, what's my point?

From what I have read, heard and discussed, in my opinion "Agile" is not a Project Management methodology and those positioning it as such are misrepresenting it in the marketplace. I would like to suggest that it is actually an approach which can be adopted when delivering "products" which form part of a project or programme. It is no magic bullet[3] which will assure success, it is not radical in its approach, and from a project management perspective it almost feels like the tail trying to wag the dog!

Don't get me wrong here; I am not saying it has no value. Nor am I saying that it cannot contribute to better project outcomes. All I am saying is that it needs to be positioned clearly and honestly so that we can extract the value it has to offer.

So what drives this opinion?

The clue is in the name. If we go back to where the "Agile" movement started and look at the Agile Manifesto, all the talk is about software development. Now call me picky, but how often does the development of software alone constitute a project? In my experience software tends to be one of the products that make up a project, rather than the project itself. This leads me to believe that as Project Managers we need to make sure that we don’t get sucked into concentrating on the wrong things, especially if we are interested in delivering successful projects and programmes?


Agile Project Management

It’s a philosophy[4], not a method! As we have seen so many times in the past the successful implementation of a philosophy is somewhat harder to achieve than the implementation of a method. Some would argue that we have a poor record of implementing methods, let alone philosophies. Prince2 being a great example of this kind of failure to execute; which in turn led to so many PINO (Prince in name only) organisations. What I see at the moment is a rush to teach the method (a new cash cow for the training companies?), whilst the philosophy appears to have a lower priority; a classic case of putting the cart before the horse.

The tail cannot wag the dog; if a development team is serious about moving to Agile they need to convince the organisation of its value and implement it as a whole philosophy within the business structure. It is only then, that the relevant tools and methods can be identified to support this philosophical change to agile.

I use "agile" rather than "Agile" to emphasise the consideration of the whole, recognising that the desired agility may also impact the method applied to the Project Management function.

It is also important to recognise that Agile may be a poor fit[5] or totally unsuitable for certain sectors or industries. Can we fly aeroplanes with a partially delivered software system, even if the most important elements have been delivered? Can we change a whole culture to allow such a change of philosophy to be implemented in say the UK Government who is talking about Agile rather than agility in their latest ICT strategy document[6]?

Don’t need Project Managers! This was, and for some still is, a war cry that is heard from those who wish to push the Agile agenda. From my research it would appear that this stems from developers' experiences of poor management, not necessarily poor Project Management; so rather than actually address the issue they decided to develop an isolationist standpoint, which puts Traditional and Agile on a war footing. Others concede that they do need a project manager[7] (of sorts) but the role is different than that seen in the traditional world and may well be combined with another role within an Agile team.

My view is, fine; you are an empowered team, capable of delivering the requested products so I will leave you to get on with it whilst I manage the whole project. BUT, I expect somebody in your team to be able to give me some updates along the way that will allow me to co-ordinate ALL the streams in the project. This will become even more critical if we have a large project with multiple Agile teams each responsible for different products which will make up the final deliverable. In Prince2 terms, this would be the Team Manager who is responsible for producing products as outlined in the Work Package and for managing a team of specialists to do it.

Reluctance to plan and document! Now in the real world how many objectives do we achieve without some semblance of a plan and appropriate document to record it? Yes, there is a valid argument that some project management methods have been implemented poorly with too high an emphasis on control of the process rather than control of the project, but surely this is something that can be easily addressed? Project Managers in all sectors, not just software development need to be taught about the concepts of "agility" and how to apply the right level of touch in everything they do. A good project manager is an ally to any member of the team and should never be seen as an enemy if they are doing their job correctly.

Agile has a role to serve in project management, but it's off to a bad start with PMs because we've incorrectly packaged what it brings in value.

Commercial reality surely demands we have some semblance of a feature set even if it is based on User stories and Epics rather than pages of written words.

This big picture will create a shared vision for the team, an essential element if we are to hit the target. In turn these will be developed into more detailed, short term goals as the detailed requirements emerge.

The features, cost and time triangle stands, whether Agile or Traditional methods are to be used, and should be surrounded by the honesty to acknowledge the reality that they will all probably have to flex. Time and cost estimates generated from the agreed high-level feature set will give a baseline against which the project can be managed and a commercial contract to be agreed between a supplier and a client; or in an internal delivery situation, some sort of cost envelope to be agreed along with a timescale and an anticipated feature set.

In summary, I would like to think that the best Project management practitioners out in the field who have been painted as "Inflexible, Command and Control obsessed Traditionalists" have, and continue to exhibit their agility, day after day. If the Agilists in the Software Development world want to press home the advances that they believe their approach will bring, they should see us as friends, not foes. After all, we need you to deliver good product, so that we can integrate them in to our projects, whilst meeting or possibly exceeding our clients’ expectation.

My call to action; Let’s be agile together!

[2] Agile - marked by an ability to think quickly; mentally acute or aware: http://dictionary.reference.com/browse/agile

[3] Agile project management: A magic bullet?: http://www.ati.es/IMG/pdf/Madrid_handout_Dalcher.pdf

[4] Philosophy - the critical study of the basic principles and concepts of a particular branch of knowledge, especially with a view to improving or reconstituting them: http://dictionary.reference.com/browse/philosophy

John Thorpe is the Managing Director of Arras People and blogs for Arras People at How to Manage a Camel. His latest presentation on the PPM Marketplace can be found here.

Perspectives on an Effective Agile Project

Words: Dan Strayer

Agile Project Management has its share of detractors. But we’ve spoken with a few of its backers as well from a variety of backgrounds. There are full-blown “agilistas” out there that can make the case for a project’s management being capably addressed by the agile way; so, too, exists the full-blown project manager who backs agile.

For good project management, buy in amongst the team members is crucial. With Agile's being of a primarily philosophical nature, buy-in is especially crucially.Until now, we’ve mostly been left to wonder what agile PM’s supporters are saying? For those on the outside of this movement, the fuss seems to be large and unaddressed. More worrying is that it may be to your professional benefit to understand just what’s going on with all of it, and the confusion inherent in the practise may leave even more clutter.

We’re here to help you with that. But to understand what stakeholders and project enablers are seeing in Agile, it is indeed essential to understand what project managers that have done it see in Agile. We recently solicited the input from several types of project people. We asked varied styles of practitioner the same set of questions regarding agile PM to get a glimpse into why it was successful for them and how it proved beneficial to them.

And it wasn’t merely a waterfall-versus-iterative line of questioning. We dug deep for fringe effects: consider sector measurement. In part because agile has mostly been synonymous with software development, scepticism is high as to whether or not other sectors can be tailored easily for management of their project. As project managers, we need to know these things.

Here’s who we turned to in order to find out the answers to these and other related questions:

  • THE AGILIST WITH PM EXPERIENCES: Carol Long told us she approaches both Agile and PM with equal consideration these days. However, having started out as a software engineer, this change programme manager tackled Agile over a decade ago. As her career has evolved, she more recently morphed into a more PM-related focus, which in turn allows her to plug in the Agile ideals she already has a great base in.
  • THE PM WITH AGILE CERTIFICATION: Geoff Filbey is a consultant for PM-Partners group who holds several certifications, including PMP, PRINCE2 and ITIL foundation. Although he’s the project manager who turned to AGILE over time, he can be credited as a full convert to the method, as he is also SCRUM certified.
  • THE PM WHO’S NOT MARRIED TO ANY CERTIFICATION: Robert Kelly might be best described to project practitioners as “agile, lower-cased”, because he’s not tied down to any particular method. Yet having worked with Agile on some projects, this acclaimed North Carolina IT project manager does have some intriguing things to say about the philosophical benefits agile brings to a project atmosphere. It’s a perspective well worth including.

What follows are our questions and the responses each practitioner gave...

  • Why does Agile work in a project?

Carol LongCarol Long: Agile is great for product development where you have a user that knows what they need but can’t define that formally and needs to see something to tweak into the final product: the build, refine, refine, refine process helps them in their discovery of the solution. The disciplines of strictly defining the time to be taken and resources available can keep a project on track from those perspectives. There are serious amounts of stakeholder involvement in defining each part of the requirements, designing the solution and defining the test to prove delivery. This stakeholder involvement can promote creative problem solving and be great for team morale because they see the positive impact of their work.

Geoff Filbey: Agile works in many applications for a variety of reasons. In my experience the most prominent reasons that Agile works are:

Geoff Filbey

-Estimating comes from actual data vs. traditional planned value approaches. Instead of using the traditional waterfall approach of using an exhaustive estimating process before execution, Agile bases cost and time estimates by measuring the performance of the project team as they do the work in the first sprint.

This data is then used to forecast overall project durations based on the measured efficiency, or velocity, of your team. Forecasts based on actual results are inherently more accurate than estimates based on prior historic data.

-Emphasis is on the team doing the work. The emphasis in Agile is on the doers. They make many of the key decisions, determine the best methods for meeting project requirements and govern their own work load and standards. This emphasis is effective in a very fundamental way as it is the people actually doing the work who are of most importance in a project team and know the “devil in the details” aspects of the specific type of work being performed. By empowering the team to control work load, create estimates, decide on approach, etc., I have seen that productivity can increase dramatically.

-Constant checking and testing during the entire project life cycle. The common misnomer that there is no planning or testing in an Agile approach is false. Planning and testing is central to Agile, but the approach is the inverse of a waterfall method. Testing and planning is built into execution. As products are built they are tested incrementally, instead of a massive go live test near the end of a project. Planning is also built into the day-to-day process, as each sprint is planned during the subsequent sprint. This allows the project team to make incremental adjustments to increase planning and testing effectiveness as the project progresses.

Robert KellyRobert Kelly: In my experience and in speaking with folks on both sides of the fence (developers and the business), the agile approach is actually fun to work. Early on it can certainly be a big shift for many: focusing on ‘right now activity’ for some has tilted towards micro-management. Some PMs have said it was difficult to find their place at first. In the end, like most things, people come to understand and feel comfortable after a few projects get under their belts. Once you get to that point, the fun kicks in...

-Many developers have said they enjoy working in a more fast-paced, rapid feedback environment.

-The business loves it because they aren’t left wondering what this will look like. They drop in the requirements and IT bangs it out. Even if it is ‘off’, the rapid comeback lets them know they have been heard and see progress...not some green, yellow bullets next to a task. They see the value being added.

-The PMs enjoy it because they have said they are feeling more buy-in from the team and the business isn’t left to make up their own assumptions that come with long development cycles (which reduces putting out fires that come with assumptions).

  • What are the subtleties to the approach that a project manager needs to understand?

CL: Agile development is a partnership between the project and its user. It is open ended in some ways but more restricted in others (requirements and acceptance test defined together before development, resources restricted, fixed duration).

GF: The Scrum Master is not a project manager. This role is more closely related to a traditional team leader.

Agile can be integrated with traditional waterfall project methodologies. They can compliment each other.

If you are going to adapt Agile into an organization, do it one small step at a time. (Using Deming’s Incremental Improvement philosophy.) If you try to implement a pure Agile approach, such as SCRUM, all at once, the behavioural adjustment will be too great.

RK: Embrace change, don’t try and manage by dictatorship, and be organized! If you are going to work in an environment that manages change rapidly and puts out features quickly, you have got to be organized as the PM. Also, this is an environment that doesn’t seem to fare well with “That’s not my job” mentalities; also, it embraces the skills of the org vs. aligning simply with function (i.e. - that systems engineer who moved to another role after 15 years, may be the best person for the job even though he/she technically isn’t in the role anymore). This collaborative approach requires the PM to be organized in the planning, communications, etc.

  • What are the major change(s) from the old, traditional way of managing projects?

CL: Most project managers are trained to deliver a set something within time and budget to satisfy stakeholders. Agile flips this round: satisfying stakeholders comes before the defined product, time and budget are even more constrained than products to be delivered. For some project managers, this makes knowing what progress means so much harder: you can no longer count complete widgets because the widget delivered is liable to be reworked at the next step. The work and product breakdown (PBS and WBS) change with each time box. You have to look at things like progress made defining and delivering against requirements: something that is not so tangible.

Agile Project ManagerDelivery will never be 100%: the nature of these projects is that you are trying to deliver the most important and urgent things in a very long list of requirements and wishes.

The resources and schedule have to be carefully managed to ensure the best stakeholder value is the focus for every step. This means how stakeholders are managed changes: procurement management acting for clients are used to defining solutions to be delivered, agile asks them to define the business problem or opportunity and the project manager may need to guide them in the difference between the two. The JFDI (just flaming do it) school of management have mistaken agile for an excuse to take action before thinking and planning. This is an approach is against the spirit of agile: there is plenty of thinking and planning in agile.

It happens much closer to the creation of the products. If this is not managed correctly, the project risks serious failure to deliver.

GF: In my experience, the most fundamental difference is how work is completed. In waterfall, the entire solution is created using a phases-gate approach. A complete design is followed by complete installation by complete testing by full go live. In Agile, pieces of the product are finished in segments. These pieces are complete and discrete chunks of work that have value. As the project moves through its life-cycle, the team creates more and more chunks of completed, free standing products. (Instead of slowly moving toward a large finished and tested product.)

RK: For me, a lot of the change has to do with the mindset of lets get this done ASAP. Who can do what now? What can add value to the business now? Whereas the old model was to develop the solution, do some testing and then pilot the whole thing.

  • Why did you/your project adopt Agile?

CL: I adopt agile practices when the project has to happen quickly with a restricted budget and schedule but has the opportunity of diverse and sustained stakeholder participation. Without stakeholders able to make consistent decisive decisions, progress stalls.

GF: To accelerate work, empower the team, respond to change quickly, start work before requirements where finished, and design as we go.

RK: With all the talk of Agile, I have still been involved with a lot of orgs that have not adopted it yet. Again, I am a fan of the environment the approach breeds...collaboration, attack the low-hanging fruit, quick decisions, and facilitate/enable vs. demand.

  • What kind of projects have you delivered in your career using Agile?

Agile Project Management RecruitmentCL: Software development, technology R&D, business strategy development, conceptual product and service design.

GF: Citrix Thin Client, Infrastructure Automation Tools and, on a completely different note, Project Management methodology creation.

RK: Business process redesign which involved changes to Salesforce and Eloqua. We were able to implement several releases to quickly capture value from the proposed solutions, while also accounting for learning curve & user adoption of the process and system changes. Even if we could push it all at once, world wide there would have been pushback. Implementing small changes, getting low hanging fruit, and developing the trust of the end-users has gone a long way to adoption.

  • Has there ever been a sort of “Eureka” moment in applying Agile to a project that really drove home why Agile as a method would prove useful in managing projects?

CL: Agile is for managing the work of project - it is not for managing projects. Managing projects is about more than producing widgets. Looking at failed projects, I began to see the difference and the strengths of agile.

GF: When I noticed team members taking far greater ownership of their actual work and celebrating successes. Using traditional methods, the people doing the work often will merely do what is asked and only what is asked. In Agile, they are much more vocal about issues they are having, ways they could work better and generally work far more creatively.

RK: No. I am still all about the Agile approach along with some other methodologies and tools. I consider myself a constant student, because I believe in building a tool box. The motto of Project/Program Management seems to be “IT depends”, so you need to have the right tool available for the job. Agile is a part of that toolset.

  • What are the top tips you have for new adoptees of the Agile approach to managing projects?

CL: -Delivering the solution is only part of managing the project: be aware of what agile does not cover because those are risk areas in governance and management.

-Define requirements very precisely one requirement at a time expressed as something measured.

-Define tests to definitively show you have met the requirement before you start on the solution.

-Involve the decision making client in the solution definition and testing.

-Prioritise for value to delivery of the whole solution when planning a time box: deliver the next most important requirements and address most dangerous risks in the next time box.

-Always deliver something that is complete at the end of every time box, put it to bed properly with all the QA and documentation in place - as if that is the end of the project, because with agile methods it may simply be good enough and that’s the time to stop spending resources on it (you don’t have to use all the budget if you can get there faster).

GF: Implement it in small steps. For example, maybe use the Daily Scrum event but in a traditional project framework before eliminating things like the WBS, status report and the like.

RK: Get involved. The PM running the IT aspects of the current project lets me join their meetings (fly on the wall) which is much more valuable then trying to read a book about it.

Dan Strayer is the Marketing Coordinator of Arras People and Editor of Project Management Tipoffs. To read more of his work on project management at How to Manage a Camel, click here

Book Review - "Integrated Cost-Schedule Risk Analysis"

Integrated Cost-Schedule Risk Analysis

Author: David Hulett
Publisher: Gower
Size: 242 pages

Reviewed by John Greenwood

About 18 months ago, I reviewed David Hulett’s book Practical Schedule Risk Analysis. The book dealt with statistical analysis of project schedules, and why common deterministic or PERT approaches generally give optimistic predictions. At the time, I thought there was space for a companion volume to deal with the analysis of cost estimates.

In Integrated Cost-Schedule Risk Analysis, Hulett has provided much more than a mere repetition of the ideas from his previous book, re-directed at cost; he has provided an approach that considers the interactions and coupling between cost uncertainty and schedule uncertainty in a complex project environment.

This book does not assume that the reader is familiar with the previous work – much of the material in the early chapters on the theory and use of statistics is repeated, covering the manipulation of independent distributions, management of correlated distributions, and the superiority of the Monte Carlo method in combining uncertainty in the time and cost estimates. A few areas where the previous book dives deep into the detail are omitted from this book, and the reader is pointed to references in the previous work. These are generally for completeness, rather than being essential to an understanding of the concepts.

For those familiar with the previous work, this book gets into its stride in Chapter 7: Preparing for Integrated Cost and Schedule Risk Analysis. The importance of robust scheduling is discussed, and pointers for the areas of uncertainty to be considered are provided. The usual criteria for scheduling and planning apply; viz. the schedule (and WBS) has to include all work to be completed on the project, tasks to be linked such that all have predecessors and successors, and resources are to be loaded. In fact, the entry point for analysis is virtually the point at which planning and estimating are considered complete by most organisations.

As expected, uncertainty of events is addressed, but the book also covers analysis of uncertainties in areas such as labour productivity and staff charge rates, and the effects these have on both time and cost of the project. Correlation of uncertainties and their effects is discussed, showing how the analysis considers how single risks can have effects at many points across a project.

Where the previous book introduced the ‘S-curve’, the cumulative probability of delivery by a given date, this book extends the idea to cumulative probability of delivery to a given cost. However, Chapter 10: Advanced Results, extends this idea by introducing time-cost scatter diagrams, where each run of the Monte Carlo simulation is plotted on a graph of cost against duration at the end of the project. This produces a ‘smear’ of points around a line, the gradient of which indicates the approximate rate of on the project, and therefore the cost impact of any time delays. This presentation also supports the calculation of the ‘Joint Confidence Level’, a contour line following those values for time and cost against which one can be, say, 80% certain of delivering.

In summary, this book extends the ideas of the previous work, and provides a thorough approach to estimating and forecasting the duration and cost on a project.  The examples demonstrate the sound statistical reasons for a significant fraction of projects overrunning in time and cost; and through explanation of the statistics and reference to commercially available tools, provides the means for an insight into the dynamics of project costs and schedules.

This book is a worthy successor to Practical Schedule Risk Analysis. Anyone with responsibility for project delivery needs to understand these effects, to be able to manage the expectations of their sponsors to understand that project schedules and costs are probabilistic in nature, and cannot be represented meaningfully by a single value.

This book is available from the Gower website at a discount to Arras People/Camel/Tipoffs readers.

ABOUT THE REVIEWER: John Greenwood has in excess of 15 years' experience in project management gained in the engineering and IT industries, and has been an active member of the PMI UK Chapter. He has worked as a Systems Engineer, and is familiar with the application of Monte Carlo methods, from his work on analysis and performance prediction of radar systems. As a Physicist, he is of course delighted to see a grand unified theory that explains project cost and time, and wonders how quality can be included.


FROM THE CAMEL: Agile Options - Training and Qualifications for PM

Atern DSDM Project Management Agile

How to Manage a Camel, the blog from Arras People, welcomes readers of Project Management Tipoffs each month with a post relevant to the topics explored in the newsletter at that particular time.

As Agile Project Management is our focus this October, Arras Managing Director Lindsay Scott offers a researched & informed treatise on the training and certifications on offer through Agile.

The post comes complete with some interesting viewpoints from the leading project management bodies of accreditation and professionalisation.

Lindsay Scott has served as Director of Arras People since its inception 10 years ago. To read more of her work on project management at How to Manage a Camel, click here.

Advertise on Tipoffs

Advertise with Project Management Tipoffs, the newsletter from Arras People

Social Media Roundup

Various Related Subjects Around the Web

From Arras People & How to Manage a Camel


Podcasts & Vodcasts

Arras on Twitter

PMI Synergy

Training Providers

Previous Editions of Tipoffs

Project Management Tipoffs Archive

Higher Education & Project Management - September 2011

Arras People introduces the Higher Education Directory and delves into the largely unexplored, possibility-laden world of university courses and degree packages now on offer for project managers.

Differentiating in the PM Marketplace
- August 2011

Arras People looks at holiday time and how thoughts about making a change in your career shouldn't be idly tossed away. We show you how to make the most of it, and introduce our Differentiate Yourself series of webpages from a recent slideshow presentation.

Stakeholders and Project Politics - July 2011

Arras People looks at stakeholder management issues as they pertain to the project management community, serving as a watch dog for the 5W-How about the people most affected by the projects you manage.

Career Development - June 2011

Arras People wants project managers to continue their professional development - this edition of Tipoffs intends to show you how, and what tools are at your disposal.

Comparing the Public & Private Sector - May 2011

Arras People checks out the current affairs and issues being faced by those within the two main sectors of employment for PPM - the public and the private sector.

Workplace Challenges - April 2011

Arras People peruses the Benchmark Report and solicits the general PPM public about the workplace issues and challenges we still face in a supposedly more inclusionary society.

Latest News from Arras People

COMING NEXT MONTH! Money...It's a Gas

Money - Get Away!For the November issue of Project Management Tipoffs, we look into whether project managers are grabbing that cash with both hands and making a stash, as Pink Floyd once sang. In preparation for the seventh annual Arras People Project Management Benchmark Survey, our managing director John Thorpe gives us a taste of the salaries & day rate information available in the marketplace of project & programme practitioners. We'll host discussions about how project managers are being compensated all month, and help you get ready to evaluate the project manager's lot in life heading into 2012.

Image from flickr courtesy oddsock; re-used with permission

Project Magazine

Our recent series of white papers in the PPM Insider tackled issues pertaining to the market conditions for project practitioners during the second quarter of 2011. PPM Insider received some well-deserved kudos in the September edition of Project magazine. Learn more about our findings in the Arras People Newsroom and at How to Manage a Camel.

Our PPM Insider white paper got some primo press from Project magazine this month. Click the image to learn more about our study on the job market for PPM practitioners last quarter.