Seven Consulting's Blog

Seven Consulting's Blog has a commitment in giving a personality and voice to it's business and brand.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login
    Login Login form
Recent blog posts

After working in and around large and small business services outsourcing deals for much of the past fifteen years, it seems to me that SLAs are often a waste of time and energy, or worse, act as a deterrent to maintaining a strong partnership relationship with service providers.

Quite the opposite of what, in theory, they are supposed to do.

Back in the early noughties when services outsourcing was gaining momentum in Australia, SLAs were a novelty to many organisations.  Enormous fun was to be had as businesses tried to get their heads around the concept of calibrating the performance of back office services, as the drive to reduce costs brought outsourcing and offshoring suddenly into vogue.  

It wasn’t just immediate cost savings on the table, but also the promise of a deep horizon of further reductions through the mysteries of process improvement, of Lean, Six Sigma and the dark arts of the black belted magicians.  Moreover, no need to knock on the Technology department’s door, with their outrageous estimates and extravagant timeframes for the simplest of changes.

The learning curve for customers and providers alike was steep.  The lure of game changing surgery to a company’s cost base fuelled the frenzy to hand over non-core services to the new breed of service providers, as companies not just in Australia but also across the US and the UK piled on to the train.  The ringfence around what were seen as core services was constantly eroding as the resistance to outsourcing was defeated piece by piece, skirmish by skirmish.  The service providers were on the crest of a business growth explosion where 30%, 40%, 50% annual revenue increases were almost the norm.

Hits: 164

"Corporate mantras focus employees' attention on an organization's reason for being. Effective mantras become a natural part of everyday conversation in the workplace and work their way into a corporation's communication with the outside world."

 When we think of a mantra, we generaly think marketing tools. A soundbite, that can often be perceieved as a couple of buzzwords, or worse a slogan designed to sell you something.

 Iconic brands throughout hisrtory continue to use simple, short, catchy phrases. But it's only those most effective at really grabbing our attention and being memorable, that inspire us to act.

 When you hear "Just do it" - you think of NIke.

When you hear "Because you're worth it" - you think of L'oreal.

Hits: 174

Most of us are used to working on projects where parts of the team are located in different areas of Australian capital cities.  But how do things change when parts of your team are located in different countries or when vendors have teams located overseas?  Here are some things to consider when working on projects with overseas teams.


Culture Is Everything


Just like every company has its own unique culture, so do countries.  And there can be variations between different team members from the same country, influenced by things like age, region, ethnic origin, gender and religion.  Being aware of a country’s culture can help things go more smoothly across the team.

I had a team, based in Sydney, with a number of team members from our software development partner in India, all of whom had relocated from Mumbai to Sydney for the project.  The software development team leader had gone back to Mumbai for the regular quarterly meetings with Head Office and his boss from Mumbai came with him when he back to Sydney.  This was the boss’s very first trip to Australia.

Hits: 386

Getting the sponsor you deserve: The 10 rules for better sponsors

I wrote this paper when I was very angry.

I had been conducting some Project Management Masterclasses for some very experienced project managers. As usual, a lot of the initial conversations were centred around how difficult life was for these project managers.

“You know, Rob, our stakeholders are too busy and we don’t get the right resources and you should meet our sponsors … they’re animals!!! ”

“All these cool tools you have shown us won’t work here because our sponsors are animals and they won’t like us using them”.

Hits: 1087

Agile vs. Waterfall Business Case and Business Requirements

One of the core differences between Agile and Waterfall is around the business case and business requirements.

The Agile business case allows for a quick start up and discovery with people who actually do the work. This has two advantages; failing fast and managing change.

Failing fast is a concept that allows the project to quickly explore the options. If it becomes apparent that the cost of the project exceeds the benefits we can stop the project. In Waterfall we would discover this same thing, however detailed requirements would have been written, review and signed off by a number of key state holders. Then having spent potentially 20 – 30% of the project budget we discover it’s not feasible. Simply put the Agile approach saves time and money allowing the business to move on to better options quickly, with little fuss.

Agile embraces change. The principle of “responding to change over following a plan” is considered by many a core strength of agile. Projects and software projects more specifically consistently change. As a product is created and comes to life or the market changes, the business should be able to react and update the product to meet the new needs of the users. Agile also realizes that requirements are emergent, they develop over time. Some great ideas are bound to come along mid-project, so having a locked down scope doesn’t work. By embracing change Agile let stakeholders and teams take advantage of these opportunities.

Hits: 4135

Understanding and ensuring accuracy of your financials is paramount to any successful project. Understanding your monthly burn rate is an important facet in staying in control of your project finances. The financial components that need to be managed include:

  1. Actuals to date (ATD)
  2. Estimate to complete (ETC)
  3. Estimate at completion (EAC)
  4. Variance to baseline budget

Financials are comprised of:

  1. Internal resource costs
  2. Internal other costs
  3. External resource costs
  4. External other costs

One of the primary tools to track financials is your resource plan. The resource plan should show the resources allocated to your project. It needs to show resource allocation on at least a monthly basis, % or number days allocated per month and skill code/billing rate. The resource plan is a primary input to the financial tracking spreadsheet. The two spreadsheets can be combined.
The financial tracking spreadsheet uses the resource plan to calculate the monthly future resource costs. The tracking spreadsheet provides two major functions:

  1. reports actuals to date
  2. calculates estimate to complete

The resource plan and tracking spreadsheet need to be reviewed and updated at least monthly.
Validating monthly actuals is a critical activity. The process is dependent on how the organisation processes timesheets, allocates costs and journals costs. In the ideal situation there would be a link between the timesheet/cost system and the financial tracking spreadsheet. If not, then the validation process is a manual process. You need to ensure that only resources actually working on your project are charging to your project and that the hours charged can be validated and appear reasonable.

In validating monthly actuals you need to ensure that any unspent funding in the current month that will now occur in future months is rolled forward into the estimate to complete.
Whilst resources are a significant cost to be tracked, other project costs also need to be tracked. Other costs can include:

Hits: 2898

Rob Thomsett, Thought Leader

On March 16th and 17th, Seven Consulting sponsored and attended the 2016 CIO Forum. Overall, the Forum was very informative with some excellent speakers (including Declan and myself … ahem). Erez Yakoni (CIO Telstra), Shalish Prakash (CIO The Washington Post), Simon Noonan (CIO Sportsbet), Lois van Waardenberg (COO Royal NZ Plunket Society), Mark Cohen (CIO Domain), John Shorter (COO, GE) and Paul Shelter (CEO Digital Transformation Office) were very impressive.
The word “disruption” and the term “digital disruption” were mentioned continuously. I lost count after 100 times.
However, to me, there was an interesting pattern that emerged that, in many ways, shows the real challenge in traditional responses to disruption.
Have a look at the following “C-level” roles mentioned during the Forum:

  • CIO   – Chief Information Officer
  • CDO – Chief Digital Officer;
  • CTO  – Chief Technical Officer;
  • CCO – Chief Change Officer (organisational change);
  • CRO – Chief Risk Officer;
  • CTO – Chief Transformation Officer;
  • CSO – Chief Security Officer;
  • CPO – Chief Privacy Officer
  • CDO – Chief Data Officer;
  • COO – Chief Operating Officer;
  • CFO – Chief Financial Officer;
  • CCEO – Chief Customer Experience Officer; and last
  • CEO - Chief Excutive Officer.

So many Chiefs and so few Indians, perhaps.
I’ll come back to this list in a minute. Other patterns that emerged were:

  • Agile is mainstream;
  • Continuous Delivery is gaining pace;
  • Talent (especially in the digital space) is hard to find;
  • Most IT organisations were facing cost contraints and cut-backs;
  • Customer-driven design is growing in adoption;
  • It’s not about technology it is about people and culture; and
  • Most CIO’s are struggling to balance keeping past alive and the future clear.

It is a pessimistic view but, the rise of new IT-related roles such as the Chief Digital Officer and Chief Data Officer is a clear indicator that traditional CIO’s have been too focused on the “legacy technologies” and managing the massive and complex mess of systems built over the past 40 years. Simply, they have misssed the boat and, worse, they are in danger of missing the future.

Great quote #1
“Its not about having a digital strategy. it’s about having a strategy for a digital world”.
Michael Salas

Hits: 1175

Posted by on in Uncategorized

In my previous post I mentioned my quality dimensions for BA outputs (clarity, measurability, coverage, traceability), what I would like to now propose is a quality management framework to ensure accountability towards these dimensions.

The key benefits of quality management are: firstly improving quality, secondly increasing the value of BA activities, and finally decreasing the risks associated to the project. In my experience there’s so much rigor applied to testing software already, but very little done to ensure that the requirements hold up to scrutiny; to address this I propose the following quality management framework:


BA Planning

Quality starts with the plan.

Quality is defined as: ‘how closely the end result(s) matches against expectations’; the importance of planning therefore is to establish the expectations of business and technical stakeholders before the commencement of BA work. This plan should include at a minimum:

Hits: 1802

This is the first of a two part series on Business Analysis: in this post I examine the case for Business Analysis [BA] within a project; the second part will propose a Quality Management framework to ensure the success of this function.

To understand the need for business analysts within a project one needs to look at the movements which gave rise to the profession.

In the late 1980’s, the growth of technology allowed mainstream organisations access to computer/information systems previously available only to defence institutions, universities and large research-houses. Gone were the large infrastructure projects necessary to get a computer system up and running, however it wasn’t all rosy: businesses began to observe that even as technology costs decreased, development costs of these systems remained static, or tended to increase with time and complexity.

This position was eventually traced back to the costs associated with re-work due to incomplete solutions. The magnification of costs for rework is illustrated below:


Hits: 1674

Multi-sourcing – has the pendulum swung too far?

Back in the mid to late 90s I was heavily involved in two major outsourcing transactions – the South Australian Government “Whole of Government” outsourcing, and the Commonwealth Bank’s “whole of IT” outsourcing, both to Electronic Data Systems (EDS), now part of Hewlett-Packard.

At that time, IT outsourcing transactions were characterised by a “single throat to choke” strategy. In other words, outsource all IT functions to a single provider, and hold them fully accountable for all IT service delivery outcomes. They also tended to be “your mess for less”, i.e. focused on delivering the same level of service, via the same delivery approach, but at a reduced cost.

In the case of CBA’s original outsourcing to EDS in 1997, the bank retained only a handful of contract administration resources, with all other IT and related resources transitioning to EDS. They soon realised that they had transitioned too many functions, and had to re-build a number of key functions, including Strategy, Architecture, Business Analysis etc.

Whilst a “single throat to choke” strategy generated a good commercial outcome with clear accountabilities, it tended not to produce the best delivery outcome as no single vendor can provide the best outcome across the broad range of IT functions. For example, the large Tier #1 vendors tend to have a mature and reliable offering around functions and technologies that have existed for a while (e.g. Data Centres and Mainframe) but lack the nimbleness and innovation that the smaller, niche players can provide, particularly around evolving and “bleeding edge” technologies.

Today, most organisations are pursuing a “best of breed” strategy, carving up their IT functions into packages that can be outsourced to separate vendors based on the best value stand-alone offering for that package.

Hits: 2056

A practical guide to Resource Management for projects and programs.


In a world full of competing priorities, more often than not the difference between success and failure on a program is the ability to identify and manage the right resources to get the job done.

There are many benefits that can be derived from well-structured resource management. I’ve found that by identifying the skills required as early as possible we dramatically improve our ability to acquire rare and hard to find skills. By knowing the resource profile required upfront we are able to work proactively to reduce the costs associated with sourcing skills externally. Putting in this effort as early as possible gives us the best chance to get the people we want. It’s worth remembering that good people are ultimately what drive a successful program.

When working in matrix environments, producing resource usage forecasts early in the lifecycle allows the program to give a clear view of resource requirements to operational managers. Getting agreements in place early to secure time commitments is critical in avoiding delays as the schedule progresses. We need to make sure that we include a profile of the resource requirements in the business case & always remember it is important to keep a focus on Resource Management through the full lifecycle of the program - its people that deliver programs!

Hits: 1554

What Makes a Good Sponsor?

The financier and philanthropist John Pierpoint Morgan once said: ‘A man has two reasons for doing things. A good reason and the real reason.’

The sponsor of any project or program, large or small, needs to possess a range of skills in order to lead and drive their initiative to a successful conclusion. These include the ability to provide vision, direction and leadership, the ability to mobilise and motivate, the ability to explain why the work is important, the ability to secure funding and resources and the ability to arbitrate and lead effective decision making. Some of these attributes are more important than others. In my experience, the most important of all is that the sponsor themselves has a strong personal reason and motivation to get the job done. This is not to suggest that any personal motivation should run counter to the corporate good, or that the motivation should be a purely selfish or mercenary one, however one question that does not get asked or examined often enough is ‘what’s in it for the sponsor?’

In order of importance, let’s consider what makes a good sponsor:

Personal motivation. Most projects will start with an explanation of the rationale for doing the work, an outline business case and an expression of the scope and scale of the task. Aside from the numeric and financial justification, it is important to consider the motivation of those involved and in particular, the motivation of the sponsor. A good sponsor should have a strong personal motivation for leading the work. It may give them a higher profile in the company and advance their career, it may help them achieve personal, financial or other targets, it may alleviate a management problem that they have today, it may enable them to eliminate or minimise a personal threat. It may be a combination of some or all of these things. Whatever the reason, a sponsor that has a strong personal reason to see the project through will be motivated to get the job done and is unlikely to be deflected along the way.

Hits: 2295

So Who Needs Change Management?

The discipline of change management (business change as opposed to technical change) has gained increasing profile over the last 20 years in the business environment.  It has moved from being the latest management ‘fad’ to being a common part of most projects and programs.  However even recently on  a reasonable size program in which I was involved we debated at length as to whether there was a need for a full time change management lead due to the relatively technical nature of the program (a data centre transformation initiative).

Perhaps the question for any reasonable size program should be why a change management stream shouldn’t be present, for the following reasons:

  1. 1)Establishing the case. The need to establish an acceptance forIn the instance of the program I’ve mentioned, a large initial investment would be required and while break-even would be achieved after 3 years, stakeholders still needed to know why it was worth spending that money.  Part of the change management function is to identify not just technical stakeholders but high power/high influence executive stakeholders, and ensure that they have at least a high level understanding of the benefits of the initiative and why it’s worth doing it now.
  1. 2)Building momentum. The need to create a ‘critical mass’ to support theAgain, using the example of this real life program, to lower the risk of multiple unplanned outages, the migrations were planned in a series of coordinated ‘move groups’.  This required agreement amongst a number of business service owners which in turn consisted of multiple applications on multiple servers.  This therefore required continual dialogue with the internal customers of these applications. 
  1. 3)Demonstrating success. The need to communicate progress and ‘wins’.  Given there are inherent risks in moving large numbers of applications and infrastructure there is a need to communicate that the moves have taken place successfully. Additionally, once some of the benefits of lower cost of ownership and reduced time for environment provision have been realised, it is also useful to provide updates around these as well.
  1. 4)Institutionalising change. The need to consolidate new ways ofEven with an infrastructure heavy project such as a data centre transformation, increased use of virtualisation technologies will eventually lead to new processes for provisioning of environments and subsequent charging.  Without forethought, development teams would have the ability to create new environments almost at will, eventually leading to a new set of problems in the future.   Therefore a change stream can help to establish the need for this change in ways of working and help to put the new processes in place.

Therefore to reiterate, even for what might appear to be a relatively technical program of work, there is always value in thinking through who might be impacted by the work, who are the more general stakeholders in the organisation as a whole, and how might the program change ways of working in future.

Paul Bernard

Hits: 1688

Posted by on in Project and Program Management

At a recent engagement we had a visiting senior executive ask the Program Manager and myself what the difference was between us.  Whilst I’m sure we both had a deep appreciation of our respective roles, it reminded me that not everyone might understand why there is value in having a separate PMO function for a program of any reasonable size, complexity or strategic importance.

In smaller projects it is usually expected that the project manager will capture and manage issues & risks, manage actions, track finances, manage change control, manage the project schedule, ensure relevant governance and approval steps are observed, and of course report on project status.  However once this scales to a program level i.e. an initiative with a number of interlinked streams all with separate schedules, deliverables and reporting, the management overhead associated with keeping track of all of the above increases dramatically and cannot be managed by a single project management resource.  Without some form of support, these critical tasks inevitably either fall by the wayside or are done poorly.  This can then set an ethos where it is ‘ok’ for actions and commitments not to be closed, issues and risks not to be actively managed, and finances not to be tracked, a precursor to failure. Whilst the accountability for managing these ‘controls’ i.e. risks, issues etc still ultimately lies with the project lead, a PMO can drive their day to day management.

This is where having a dedicated PMO comes in. Without this a Program Manager would spend the majority of their time focussing on these activities and therefore not focussing on delivering the program, including stakeholder management, ‘putting out fires’, ensuring the program is delivering the benefits it promised, driving closure on actions, issues and risks and ensuring a cohesive team is formed and all the other expectations that fall to the project lead. Once again, a good PMO can support the Program Manager to ensure all of the above are not overlooked.

The PMO will also play a very active role in ensuring consistent scheduling, budgeting and general delivery practices are maintained across a program, as well as ensuring said schedules and budgets are regularly updated and integrated.

A strong value-adding PMO will work closely with both the Program Manager and the stream leads to ensure reporting is compiled on a regular basis and distributed in an easily understandable format to the relevant stakeholders, thereby enabling a much better understanding of how the program is tracking and where management support and attention should be focused.

Hits: 2475

The Importance of Communications

Recently I set up the PMO for a data centre transformation program an initiative, to consolidate and move several thousand computer servers from a number of locations into two new facilities, requiring a number of concurrent project streams under an overall ‘program’. As part of the set-up, I wrote and then enacted the communications plan for the program.

Now you might ask why such a technically orientated program might require such a formal, planned approach to communications.  Well such an approach enabled several important outcomes:

·    Heightened overall awareness of the program and gave anyone involved in, or impacted by, the program an opportunity to find out the program status;

·    It gave an opportunity to engage stakeholders early (and throughout the life of the project), some of whom’s buy-in would be become important later on in the program when it came to planning and executing the migrations of the servers themselves;

Hits: 1947


Whilst running the finance function for an IT department I had to mentor a team member whom compiled the monthly reports for the management team. He was of the view that compiling a snapshot of the budgets and actuals for the month for the entire department and sending this out with around 100 rows of information was sufficient. This team member was a very experienced and capable accountant.

Whilst this approach might have been enough for an audience of other finance professionals, it did not provide the management information to enable a group of non financial managers to first of all understand how we were tracking against our budgets, but more importantly be able to make informed decisions about budget allocations and what effect these would have. This is what I term the difference between raw ‘data’ and useful actionable ‘information’.

In the example above, over time we worked together to include the following to bring the report to life:

  • A 3 month view of whether we had been tracking under or over budget to spot any emerging trends;
  • Drilldowns on particular areas of underspend or overspend to identify contributing factors to bottom line;
  • Consolidated our project delivery data at a portfolio level to identify what remaining delivery capacity the department had as a whole for the rest of the financial year; and
  • Probably of most value, a brief bullet point written commentary on the budget

Over time we moved from a management team whom were struggling to work their way through the spread sheet and were not engaged, to a team that were happy to spend half an hour discussing where our finances and resources were best directed and employed.

Hits: 2094

The problems with change requests

Most Projects apply change controls to manage Program scope, so why do most Programs run late and have scope control as a major cause of the delay? There are a number of reasons but one that I’ll look at this month is the hidden impacts of change.

Programs generally look at the effort required to make the change, e.g. developers, testers etc, say $1k per day * 40 days = $40k. Payback on the change is $100k a year, so it looks like a good business case on the surface.

However, the full cost of the change is not just the effort directly associated with the change but the impact on the overall Program timeline.

If the change impacts the critical path for the Program, the costs could be as high as the total Program running costs by the number of days by which the change impacts.

Hits: 2602

The Importance of managing informal stakeholders

It has been said that project success is not only whether the project/program has been delivered on time, within budget, to scope and to specification. It is also about the perception of stakeholders. Delivering a good project is not only about the project management outcome, it is also about how successful a journey you have taken your stakeholders on.

Stakeholders change through the life cycle of any project. From initiation, planning, execution, monitoring through to closure. This article is not about how to select stakeholders. As the Project Manager, you should be able to work through the methodology and processes to identify your stakeholders. It is about how you should engage your informal stakeholders (stakeholders whom have not been identified as formal but are impacted by project delivery or vice versa) as well as your formal stakeholders in order to deliver a successful project/program.

Informal stakeholders can impact the project delivery success. This is not deliberate as they are simply doing their job of managing and minimising risks to their area of responsibility. It is the responsibility of the Project Manager to engage these individuals and to gain their trust and support.

There are two examples I can share from recent programs I managed to emphasise the importance of managing informal stakeholders.

Hits: 5918

Posted by on in Project and Program Management Office

Cost management

Projects nearly always start off with a budget and it is the role of the project manager to deliver the project within the allocated amount.

Regular reporting of costs to the project sponsor/stakeholders is critical. This should be done on a monthly (or more frequent) basis. Sponsors are never happy about projects that go over budget.

The key components to manage are:

  • Have a cost plan that describes what the budget is by expense type and the basis of the estimates that were used to develop the budget
  • How variations to the plan will be managed
  • The timing of expenditure
  • Cost reporting (what will be reported, who to and the frequency).
  • Include cost contingency and how it will be managed.
  • Who can authorise expenditure.

The key components to report are:

Hits: 2214

Posted by on in Project and Program Management Office

Schedule Management

Having an up to date schedule is critical to the management of programs and projects. Too often Project Managers try to manage using schedules that are not up to date or do not reflect reality. This often results in projects running late and some interesting conversations with sponsors and stakeholders down the track.

Some key tips to ensure that you have an up to date schedule that everyone has confidence in:

  1. Get schedule updates from the team on a regular basis. Weekly or more frequently is best. Ideally this is done in a face to face meeting or teleconference so that you can have a discussion about any variances.
  2. As soon as you can get agreement to the schedule, set the baseline. This will provide a solid basis on which to move forward and provide some certainty about when milestones will occur.
  3. Ensure all tasks have an owner who is responsible for reporting on the tasks.
  4. Any tasks that are due to have started should be reporting progress. If tasks are still showing 0% complete, then they haven’t started yet and you need to know the start date.
  5. Any task that has a finish date in the past should be 100% complete. Otherwise the finish date is wrong and needs to be updated.
  6. During the update, the task owner should be asked to confirm the planned finish date for each of the started tasks.
  7. The remaining work for a task should be realistic in terms of the resources assigned. Avoid the classic – 90% of software projects are 90% complete 90% of the time.
  8. Ensure that the schedule is constructed correctly 
    • all tasks have predecessors and successors,
    • dependencies are not linked to summary tasks,
    • all tasks (except summary tasks or milestones) have resources assigned,
    • resources are not over-allocated 8.5. Avoid hard dates unless they are external constraints,
    • Where possible, have objective, measurable exit criteria for tasks,
    • Keep task durations ideally under 10 days. This will be the maximum delay that can be incurred without a flag being raised
  9. Task owners need to provide reasons why tasks are running late (or early) and should have a plan for bringing the tasks back to the planned schedule, if late.
  10. Monitor the variance to previously reported start and finish dates (whether or not the schedule has been baselined).
  11. Monitor the total slack and free slack for each task so that you can be aware of tasks that are on or getting close to the critical path.

Having an up to date schedule that reflects where the project is really at will give the project team, sponsors and stakeholders confidence that you will deliver on time (or that you know where the problems are so that you can take corrective action).

I have worked on many projects and those where there has been a well-constructed and well-managed schedule have generally been more successful than those where the schedule didn’t reflect where the project is up to and where it was going.

Hits: 1855