Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Agile Development

Friday rant … inventing process for HR / finance


Friday-rant-inventing-process-for-hr-financeI remember having to study Accounting 101 when I studied Information Systems. At the time I had wondered what the purpose of it was. The rationale given was that 80% of software is written either for or because of bean counters. More time goes by, I am seeing businesses becoming agile and learning new ways to deliver services faster and in a more competitive way.

Sadly, the accounting and HR systems seem not to have caught up with this. When you and a customer can commercially agree a mutually beneficial business model, it becomes a chore to then translate that into the internal system. More often than not, It cannot be done, as the processes have not thought about these ‘revolutionary’ possibilities. These are systems that are sticklers for process and you end up working your existing systems to somehow shoehorn these new models.

Organisations must realise they can only be as agile as their least agile part of the business. Otherwise you get into a tangle trying to respond quick with your front office, but end up inventing process to placate your back office.

Anyone else grapple with similar issues?

Image credit: dwmbeancounter.com

Where is the line between agility and chaos?


We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

Do procurement processes allow Agile software delivery?


Longer projects run, higher likelihood of project failure. One of the moves in recent times to reduce complexity in software development is to adopt Agile delivery approaches. The desire to build confidence and leave tangible benefits even if projects are cancelled has provided further impetus to adoption of Agile practices. This approach has delivered good outcomes for teams that work in in-house and product development teams. However, challenge remains in successful adoption Agile practices in contracted deliveries.

It is rarely the willingness of the project teams or suppliers that is the barrier, but the way organisations work. A quick review of how most organisations initiate projects will highlight this. In most organisations operational staff will identify areas of improvement. Organisations have processes to provide feedback to management to achieve this. Management then compile business case, which is then reviewed and approved by the organisation. It then moves through the procurement cycle, supplier selected and contracts agreed. These contracts are on the basis of deliverables (outputs in PRINCE2) from the project, rather than benefits.

Let us now review the consequence. The project is set up with A, B and C as deliverables. As the project starts, it becomes clear that modifying B will provide far more benefit, even if C is dropped off altogether. In an agile project, the customer is able to provide immediate feedback and the product backlog would be adjusted accordingly. Here the project team consists of suppliers who are under contract to deliver C. They cannot alter the required deliverables. The project team from within the organisation is also not authorised to make this adjustment.

As you keep moving up the organisation challenges still remain. Project governance is set up to hold people accountable for the delivery. Benefits are more difficult to quantify than outputs. Therefore the culture is usually to hold people accountable for the outputs. Modifications to business cases are usually treated as acknowledgement of omission, rather than as an evolution of the project.

So why this inertia for reviewing the deliverables in order to extract the best benefit? Consider what else the people in charge of procurement acquire for the organisation. For most things they are able to show something tangible – an air conditioning unit, an executive table, a new building. Other things they procure are services that are usually measured in time – 3 weeks of consulting. Software development is somewhere in between. You have time, the deliverable is something abstract and it is difficult to judge whether you got what you had asked for – a lot of grey areas. The people to judge is often not the ones that approve the procurement or control them. Auditing the procurement is therefore difficult terms of benefits. As a result you end up with controls on outputs.

In order to successfully embrace Agile delivery practices it is imperative that procurement and auditing methods in the organisation is geared towards measuring benefits, rather than outputs.

%d bloggers like this: