Archive | Project Management

How to Structure Your Agile Enterprise

By Christian on 11th February 2014 in Agile, CIO, Enterprise, Leadership, Project Management

First of all… this is a really, really, really big topic. If we are lucky, we’ll get a start and maybe lay a foundation for future conversations. My goal in the next 1000 words or so is to at least introduce the foundational concepts, and frankly… help me see where I want to go with this. So… with all my pre-qualifications in place, let’s see what we can do.

Over the last few posts, we’ve talked about what it takes to do Scrum well and explored many of the anti-patterns that cause Scrum to fail. One of the biggest challenges to adopting Scrum is the ability to form complete cross-functional teams. Before we get into how to solve the problem, let’s first explore why it’s so hard to begin with.

Continue Reading →

Is outsourcing the question or the answer?

By Christian on 8th November 2013 in CEO, CFO, CIO, Communication, Contract Negotiation, IT Director, IT Leadership, Leadership, Outsourcing, Planning, Project Management, Risk, ROI, Strategy, Vendor Management

Once upon a time, the answer to the question of what are the main benefits of outsourcing was cost savings based on labour arbitrage, but today that response would be superficial and incomplete.

I believe the main benefits of outsourcing are access to scarce skills, expertise and the latest technology, cost reduction, turning capital expenditure into operating expenditure, and the opportunity to concentrate resources on core business objectives.
If you think about outsourcing in this manner, you will not only start to realise areas within your IT organisation that would benefit from adopting it but also ways as a strategic leader you can add further value to your entire organisation by doing so.

The first big error people make when considering outsourcing is looking to resolve a problem without first looking to do so in-house – a problem remains a problem no matter where it sits.
Sensible outsourcing providers will often sniff this out during the RFP or other stages of the bidding process but others may look to take it on, hoping they can fix the issue(s) as a calculated risk whilst trying to win the business (the fact a vendor accepts this huge risk should really start ringing alarm bells for you as you both know there’s an elephant in the room).
Those that don’t take the business (and hopefully this is the majority) will likely make you consider going back and fixing the problem before re-tendering. Those who take it on will only delay the inevitable, leaving you not only with a larger problem downstream but also with the added bonus of a whole heap of complex contractual issues to sort out (which I imagine you will now discover were also not properly agreed or worded up front).
Many take this approach and get their fingers burnt with outsourcing, vowing never to return.
It’s a real shame, as outsourcing done in the right way is an extremely beneficial way to add to the value you provide to your organisation.

The second biggest error people make when considering outsourcing is to engage with and select a vendor by having only had a few live sales meetings/conference calls with a cursory glance over provided case studies. Coupled without ever having visited their operating/service centres to see them in action in a live environment or meet their staff that will be working with your team in person.
You wouldn’t do this if you were hiring permanent staff or running the project in-house, so why do this when exploring outsourcing? It makes no sense.
This often occurs when a company decides to outsource a small project or a portion of it to see if outsourcing works for them in an operational sense.
The vendor is often chosen just on labour arbitrage and due to this the work is often performed in Asia or Eastern Europe.
The ‘project’ is often then left with the vendor with scant and seemingly erratic communication and only poured over in detail once the deliverable is returned with obvious errors.
The end result is the project often has to be redone in-house, blowing the project budget, causing delays and delivering red faces all round.
Outsourcing is again blamed as the enemy with the lack of communication and poor vendor selection/interaction issues being swept conveniently under the carpet.

So, in reflection it may be outsourcing is not for you but you owe it to yourself and your organisation to try everything that can add value to what you deliver.
Outsourcing executed properly can provide real value when opportunities are identified, structured, communicated and managed correctly, so what are you waiting for?

This piece has also been posted on:
The Intel IT Peer Network in my position as IT Industry ‘Thought Leader’ and Featured Blogger
The Business Value Exchange in my position as CIO ‘Thought Leader’ and Featured Contributor
Outsource Magazine in my position as IT Industry ‘Thought Leader’ and Featured Columnist

Roles and responsibilities of key stakeholders

By Christian on 18th September 2013 in Agile, CEO, CFO, Change Management, CIO, Governance, Project Management, Risk, Stakeholder Management, Stakeholders, Transition

Key stakeholders for any project typically come from inside your organisation and are normally those who have endorsed or identified the need for project activity. However they could also be external clients or suppliers, as they might be directly affected by the resulting changes of the project.

They need to be identified prior to the project proposal being discussed and be the driving force and sponsor for the project through all stages from development to training, implementation and support.

The key stakeholder is a pivotal role in the success of any project and they have a number of core responsibilities that they must adhere to.

Understanding the business drivers and ensuring that the project fits with the strategy for their area of the business: a fundamental responsibility – the stakeholder must be able to clearly explain the necessity for their project to be taken on before others and prove its strategic merit.

Providing detailed requirements and a financial plan: every project must have these and is doomed to fail if they’re not completed up front.

Committing the necessary resources: Its key to have individuals from the affected areas involved on any project. They can provide you with instant answers and feedback as to how things do or should work. They are the daily operational link to the eventual user base of the project deliverables and I cannot stress enough the importance and usefulness of having them involved. Agile PM methodologies allow you to have quicker bursts of development and a higher pace of deliverable but if you are using traditional project management techniques and don’t have target resources available, you could be wasting a whole heap of time and reputation if your deliverables don’t match what the client wants.

Taking ownership of appropriate deliverables: the stakeholder needs to take ownership of the appropriate deliverables and make sure that they work against a number of key elements such as mirroring the requirements, process compatibility, usability and performance. They must sign off and take ownership of each deliverable, thus allowing the project to proceed on the right track.

Keeping abreast of project progress and cascading information to others who need to know: the stakeholder must not skip project meetings and rely upon others to keep them up to speed. Similarly, they must also keep affected others or teams up to date with frequent progress reports. This is probably the most often reported symptom of failed projects where key stakeholders become disassociated with a project and it starts to drift, stray from the requirements and fall apart. Stakeholders must stay focused and attend all key project meetings.

Establish the training and support requirements: the stakeholder must identify any effected individuals of their projects and establish the necessary training and support requirements. This will be done in harness with the relevant departments but the stakeholder is responsible for it. A project should not end when the development is finished but when it is fully implemented with full training and relevant support models.

Identifying and resolving any project issues and risks, especially those associated with managing change during the transition phase: it’s up to the stakeholder to identify and acknowledge any potential risk and change associated with their project during the proposal stages. This will obviously be discussed with the project team, PMO or legal representatives prior to the project getting a green light.

Communicating throughout the life of the project: I cannot stress enough the need for strong communication. The least successful projects are the ones that are done in isolation, that people forget about until an email gets sent around heralding its imminent implementation. Requirements or processes sometimes change during project development and without having relevant resource or communication with the targeted business areas, a project will quickly lose resonance and relevance. Managing associated change during the transition phase must be done up front or during the life of the project and not when its ready to be implemented as those reticent to change can quickly sour any implementation.

Project closure: in accordance with good project governance, the stakeholder must perform an analysis of the projects delivery against plan, budget and strategic objectives and sign off and accept the project.

This piece has also been posted on my Outsource Magazine column here and on The Business Value Exchange in my position as CIO ‘Thought Leader’.