I fall naturally into leadership roles and have become passionate about what ‘good leadership’ means.

Personally, I think it is being able to get the best from a team by setting a good culture, sensible (stretch) deadlines, good quality standards and not asking team members to do things which I would not do (if I had the skills / availability).  It’s also about ensuring people have the right tools, access to resources and access to people, and empowerment to make decisions to get on with what they need to do.

As a leader I tend to be focussed on joining the dots to other teams, planning ahead and watching out to see whether areas need support / bolstering.  Reviewing work complete is also critical in preventing problems before they become systemic.  A good example of the last point is documentation: if the template does not fit the task, and if the team member doesn’t communicate this, then the only way it will be spotted before it’s too late is through a review.

Here are some examples of leadership roles I’ve held / undertaken:

  • Process Owner (Order to Cash)
  • Stream Lead
  • Team Lead
  • Project Manager
  • Programme Manager
  • Competency Centre Manager
  • Partnership Manager
  • Engagement Manager (not formally, but that’s what I was doing across consulting gigs)
  • Consulting Manager

In terms of methods, very early on I was working closely with people that were certified PMP – then when I came to the UK it was mainly Prince II.  I’m ASAP Focus Certified, which is IMO a pre-cursor to the Activate methodology (the DNA is the same and closer than the original ASAP).  Because of the focus on ‘out of the box’ (demonstrate standard) functionality first, it is a sure fire way to avoid some of the large amounts of effort consumed in blueprinting what should be vanilla (non-differentiated) processes such as AP, within a client organisation.  I tend to think if there is an IDES available, then demonstrations of standard functionality will demonstrate the art of the possible far better than discussions.

I’m a fan of using agile methods (stories, scoring, sprints) to achieve individual lines within a project plan, where the iterative method informs the design better than countless reviews of a specification.  But, where external / outsourced resources or more junior programmers are involved, the tried-and-tested specify, approve, communicate, review, hand-over ways of working are frequently the only choices available.  In the case of the latter, reviewing the specification together is generally the most productive and illuminating aspect.