Archive for the 'Project Management' Category

The Absent Stakeholder

Published August 26, 2009 Project Management Leave a Comment
Tags: , , , , , , , , , ,

Your stakeholder has gone missing! A senior executive who holds many budget strings for the whole organisational unit of your corporate firm, he is not answering your emails, not attending project meetings, and since his corporate diary is not visible to you it’s not possible to judge his whereabouts or reschedule to a different slot. He sits in a different building so you are unlikely to see him in the corridor to say hello and remind him of the next scheduled steering group meeting.  But you know he’s senior and busy, so maybe that’s to be expected. Perhaps you are a bit in awe of him and don’t dare call him directly – your one voicemail has gone unanswered so you don’t dare pester him again.

The project is already underway and analysis is getting into full swing. It’s your first large software project and you are keen to impress your VP with how capable you are. Your ultra-busy VP has told you that there is budget for this initiative and it sounds like it has been approved by your stakeholder. You don’t know – you were not there – but you trust her. So far no ongoing issues, you report on your weekly report – on track with analysis and no complaints – the analysts are working hard and future users seem cooperative in discussing requirements. And yet you have this dull, nasty, worried and annoying feeling in the pit of your stomach just thinking of your stakeholder. Why is he ignoring you? It is personal?! Does he not care all the trouble you’ve gone to to get this far? Yet since all is quiet you carry on.

This PM is right to feel concerned. What a potential disaster waiting to happen - and this PM is not really seeing it coming. No news is not good news with stakeholder engagement. The team might well be heading for a project that is stopped and all funding pulled, or they could end up deliver something no-one wants, or there could be a massive row with the sponsor about the current lack of proper engagement.

I’ve seen projects in that boat and it never ends well. Money and time gets wasted, reputations suffer, relationships between organisational units get strained. Deal with this emergency situation immediately: you’ve lost the attention of your project sponsor and it needs to be regained at all costs. Or perhaps you never had the right person; the correct senior executive must be engaged asap.

Communication and engagement are two cornerstones of a successful project. Get these right and you are well set for the rest of the process. Chances are that faulty or absent communication, as well as shoddy stakeholder analysis, are at the core of many troubled projects.

There are several things a PM must do to rescue the situation:

- Communicate: Check you used the right communication methods with your stakeholder. A phonecall is far better than an email. A face-to-face meeting is far better than a phonecall. Call your contact and schedule a meeting in his diary via his PA. You will find that a meeting might well achieve where a dozen emails failed. You should agree ground rules for working together to ensure project success.

And whilst you are at it, check that you know and use the best way to communicate with all your project participants.

- Engage: Review your stakeholder engagement map. If you don’t have one already- write it up. It is essential to know your stakeholders – have you got the right people involved? What do you need from them, and what do they need from you? Are they going to assist you or block your progress? Do you need to influence them to convert your blockers to supporters? 

Map it all out and link your stakeholder mapping analysis into your communication plan.

Finally,

- Recognise potential issues: Tell your manager about this problem, don’t sit on it until it’s too late.

I am not suggesting that you escalate to get your boss to deal with the problem instead of yourself, but in some hierarchy-conscious organisations someone might be seen as too junior to deal with senior executives and gets ignored. It’s a terribly unprofessional practice, of course, but it’s something to be aware of.

Ksenia Woodgate

Project management with a healthy degree of paranoia

Published August 17, 2009 Project Management 2 Comments
Tags: , , , , , , ,

Whether or not one is a natually paranoid person only one’s closest friends and family can really judge. However when it comes to overseeing projects, a PM – in my opinion – has to develop a healthy degree of paranoia, regardless of their natural predisposition. And I think that’s the right – no, the essential – attitude to have in this job. Let me explain what I mean by that.

It’s really a combination of things: attitudes and qualities such as “close attention to detail”, “leaving no stone unturned”, and most importantly, “never making any assumptions”. This does not mean the PM has to do everything on a project and be everywhere at the same time, constantly breathing down people’s necks - that would clearly be unrealistic as well as annoying and unworkable for the team as a whole. PMs can and ought to delegate tasks. But even with delegating, a PM must invest a serious amount of effort to establish a reporting feedback loop and an accountability framework which then creates an environment of open, transparent and constant communication across the team and with the stakeholders. And when not delegating, a PM must make it their business to fully understand the subject matter or seek reliable expert help to ensure success. It’s common sense to all good PMs.

Project management is as much as art as it is a process. Much has been written about the process aspect of project management, and there are excellent tools available for PMs. However a part of the art of successful project management is to have this gut feel, this instinct for  sensing potential future trouble when there exists at least the tiniest lack of clarity about something the team is engaged in. And a healthily paranoid project manager should realise that if there is a little bit of scope for something going wrong as soon an a little gap in communication opens up, things will indeed go wrong given half a chance. Any unchecked assumption can blow up in your face.

So working with this instinct, a project manager should be continuously checking and validating in detail any assumptions they might have made, confirming everyone’s understanding of tasks and deadlines,  ensure sensible and pragratic process is followed, bringing people together to collaborate better, and thus work on ensuring total clarity throughout the project lifecycle.

The other day, a client with whom we’ve been working for some time asked us to proceed on a piece of work by sending me a quick note saying “please commence the work”. Some specification documents have been written, and a summary of estimated costs has of course also been presented in the past. But the client has not signed off on these in an explicit way (we are not using a document approval system with them at this present moment).

To a project manager, this lack of an explicit approval should be a concern – and my paranoia, my gut instinct tells me that this needs to be sorted out. Even though documents have been swapped at the same time as the informal approval, such a situation can be misconstrued in future and perhaps someone could claim that sign off has never been given. We would not want to risk such a situation developing, so – call me paranoid – I am seeking to have a more formal written acknowledgement of my documents.

And maybe this is a bit formalistic – and perhaps even a bit annoying to our customer whom we know well and for whom we’ve successfully delivered projects in the past. But as long as everyone is clear on the implications of this situation and the risks that both parties expose themselves to, then better and clearer communication will follow and I think we will get the project kicked off properfly in the very nearest future.

You can call it the art of project management; or you can call it common sense.

Ksenia Woodgate

Agile development – on lack of trust as a roadblock

Published August 6, 2009 Project Management 3 Comments
Tags: , , , , , , , , ,

Many IT organisations have faced a question whether or not to develop using Agile as part of their change management process. It has its own well documented merits – such as ability to empower and motivate teams and increase their throughput, as well as deliver a product that meets the customer’s needs very well. A highly motivated team is also more likely to display a greater ability to innovate – a winner all around!

As a project manager reasonably new to “Agile with Scrum” – we are keep to use it at PointBeyond and we tried that in my previous jobs, occasionally with somewhat mixed results – I wanted to share my own thoughts on the suitability of Agile to organisations’ project management processes.

It seems a good idea to carefully evaluate whether or not to adopt Agile, and to what degree to adopt it, on a case by case basis. There are places where a traditional Waterfall approach could still work. In others, Agile can be of huge benefit. It depends.

From my own experience, I can see two areas where Agile and Scrum might not work all that well. Both cases relate to organisations with cultures that are more regimented, and where trust can be an issue.

The first case is where a customer needs to fully understand the end deliverable before signing off on the dotted line to commence the project. So we are talking about a customer who is fairly inflexible in their approach. To receive a go-ahead to actually start building software, one would then need to put in place a comprehensive functional specification – which will be arrived at after a full-on analysis and design phase.

Of course, going Agile does not mean that the functional specification is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. But not all customers will grant such a degree of artistic license to the project team. And hence it can also be a question of trust in one’s professional ability, judgement and skill – is there enough of it between the customer and the vendor? Can the customer “let go” and empower the project team to work out the smaller details using a suitable Agile methodology as the project carries on, or will every question need answering in advance?

The second case is where an organisation’s senior management interferes with the Scrum process, perhaps wanting teams to achieve unrealistic targets and add to its list over and above what teams say they can do – or maybe insists on changes of priorities at short notice and still expect excellent results.

Such an approach can be destructive for any team trying to implement Scrum, as it will cancel the efforts made by the participants to work out their own capacity and commit to work on their own initiative and own understanding of their skillset. Senior management must fully buy into the Agile process and remain strictly at arm’s length. If it does not, the process will not work efficiently and result in lesser motivation and decreased productivity.

The Scrum process allows for priority calls to be made – but only at the start of each Sprint. If, half-way through a Sprint, serious external circumstances cause a massive shift in priorities rendering the current Sprint a total waste of time, the Sprint can be stopped – and this is the only time this is allowed. However if an organisation tries to change priorities half-way through a Sprint by introducing new key items into a committed iteration, whilst Scrum masters allow this to happen under pressure from management, the process can break down. Needless to say, this causes stress to all participants and often does not get the item done on time anyway.

Yet again, we are talking about trust. This time – in implementing Agile – it is between senior management of an organisation and its Product owner, the Project team, and the team’s Scrum Master. When an organisation fully empowers its employees to deliver (whichever change management method is preferred) and gives them all suitable tools to do so, it will have the greatest chance of success. And trust in it’s teams is a huge step towards such empowerment.

Ksenia Woodgate

Our Contributors:

Ian Woodgate, MD; Sam Pike, Senior Consultant; Andrew Webster, Senior Consultant; Chris Edgington, Business Development; Ksenia Woodgate, Senior PM

 

September 2010
M T W T F S S
« Jul    
 12345
6789101112
13141516171819
20212223242526
27282930