Category: Uncategorized
Negotiation for Project Managers

Negotiation is defined as “a discussion aimed at reaching an agreement” (Oxford). An elegant and simple definition encompassing yet a powerful and sometimes hard to master skill, especially for project managers (PMs). Here’s why:

Projects involve change. Many parties interact during a project lifecycle including stakeholders, users and delivery team. Sponsors empower PMs to deliver, however, it should be no surprise to PMs that conflicts arise in projects due to many sources including matrix organisations, conflicting priorities, expectations gap and scope creep. Without an effective way to solve conflicts in a timely manner, projects can quickly come to a standstill and may even fail.

The good news is that by mastering and applying these negotiation skills in day-to-day activities, PMs can ensure progress through even the most difficult of conflicts. Read on to take a look at how to apply negotiation skills effectively from a PM’s perspective.

What is negotiation for PMs?

Negotiation in projects is about finding timely solutions to conflicts that arise between people linked to the project and/or impact it in some way. Negotiation is a highly effective interpersonal skill that PMs must master to move projects progressively. Finding an ‘agreed’ solution that either:

  • Benefits all parties – means everyone got, or at least feels they got, what they were after from negotiations. A solution acceptable to all is usually the one that builds great teams and enjoys best support afterwards
  • Benefits some of the parties or one only – means someone had to compromise (take one for the team) probably for the greater good of the project
  • Just escalates the conflict to next level in project governance since the negotiations could not reach any agreement

An agreed solution that benefits all parties is also often called a ‘win-win’ scenario and is the most desirable outcome PMs want from their project negotiations.

Why do PMs negotiate

Temporary endeavors to achieve something unique, projects typically require some form of ‘agreement’ from time to time between those delivering change and those who will use or benefit from it in future (like users, stakeholders and outside world). To name a few:

  • Requirements, scope and resources agreed during Planning & Initiation
  • Deliverables and milestones accepted during Delivery & Implementation
  • Changes to scope controlled and agreed during Monitoring & Control
  • Sign-offs and project handover at Closing

Who do PMs negotiate with

For PMs, formal and/or informal negotiations happens everyday. With project’s success as focus all the time – PMs are always negotiating solutions. Engage these groups throughout the lifecycle of the project and negotiate timely solutions to any conflicts that risk your project:

  • Users (requirements management) – negotiate project requirements with users (or their representatives) to finalise scope. Being the end beneficiary of what your project will deliver, effective negotiations with users help set right expectations from start and will make acceptance, handover and closing smooth.

  • Suppliers and vendors (contract management) – formal negotiations to select best supplier/vendor for delivery and after a contract is awarded, negotiations continue in matters of contractual compliance, performance and any changes needed. It is best for PMs to seek specialist support from Legal and Procurement during these negotiations.
  • Team members (and their managers) – your project team is the centre of it all, moving the team together as one unit requires regular internal sync ups, prioritisation calls and agreements on the implementation strategies. Negotiations here are very informal but lead to highly effective collaborative work. As PM, you should also expect to negotiate with line managers of the project team in a matrix environment.
  • Stakeholders (stakeholder management) – negotiate project scope, time, cost and quality with stakeholders as well as seek their buy-in on scope changes, risk mitigations, contingency funds (if needed) and commitments on organisational resources for the project. Honest and open communications here are necessary to manage stakeholder expectations.

How to negotiate
Now we get into the mechanics of how should PMs negotiate in a typical project setting. Project negotiations could be segregated into following distinct phases:


Let’s see what happens within each:

  • Plan: Plan for negotiations ahead – do your homework. Gather background information on the topic, set targets, know your tolerances around the targets.
  • Discuss: That’s where the actual negotiations start. PMs lead the discussion – keep them from digressing off topic. Open negotiations by setting the scene – introduce key issues to discuss. Remember to listen, paraphrase key points to ensure common understanding and keep driving the discussions forward.
  • Propose: Brainstorm, propose solutions and listen to solutions being proposed. Focus on reaching agreements. Communicate clearly and openly.
  • Bargain: Be prepared to trade-offs and give & take. Show flexibility to reach a plausible agreement. Your homework of knowing your tolerances will pay off here.
  • Agree: Reaching an agreeable solution is the real goal. Be mindful of the fact that the agreement could be one of many types explained above. In all cases, ensure you get it in-writing/signed-off from participants. Summarise conclusions for all and later distribute minutes appropriately.
  • Review: Following up on the resolution of agreement is essential. Ensure all parties are kept informed of next steps taken. Update any impacted project documents.

By now you should have a good sense of how important negotiation skills are for the successful delivery of projects. Effective negotiations could literally turn people in opposition of the change your project delivers to its biggest supporters. They could be the missing link to get those stumbling blocks out of your project’s way to success. Take time to prepare well for your negotiations, be reasonable and respectful, listen to others’ views and remain focused and calm all the time. A proven ability and a track record to reach ‘win-win’ solutions – of which there are sometimes many in difficult situations – is a hard sought after skill in Project Managers. I hope these thoughts will help you master this skill.

I leave you with a question: Have you faced a situation where it was difficult to make everyone happy, but yet, you were able to carve out a ‘win-win’ scenario? Reiterating points of common benefit could sometimes help people let go a little to reach an agreement – please share your thoughts. Cheers.

Some information here is sourced from articles in Association of Project Management.

Rana Ali Saeed – Rana is a Project Manager and Technology Solutions professional, having served clients in IT, telecommunications and academia sectors for past thirteen years. These years have probably experienced the fastest wave of technological change. The explosion of digital data touched almost every industry and the demand of data speeds grew exponentially. Telcos evolved from 2G to 5G and smartphones became a commodity from once a luxury. Having ridden this wave of change, Rana has a passion for taking on new challenges. He is enthusiastic about Data Science (analytics, visualisation, presentation) and currently spends his leisure time as a student of Machine Learning, Deep Learning and Inferential Statistics.

This is how we do it! – IMA Sydney Christmas Party 2016

Balmy sea breezes, iconic Sydney Harbour backdrop, free flowing Christmas ‘bubbles’ and a cracking dance mix plucked straight from the 80’s and 90’s – that’s how we do it in Sydney!

And what a night it was . . .

As the Christmas canapés were passed around, we reflected on the year that was, made some new friends, relaxed into the Christmas spirit and admired the history of The Rocks precinct. Arch as always, did an expert job with the food and wine and even found herself running a little education session with the DJ on rules of vegetarian. Sorry darl – lamb is not a vegetable!

A few hours in as the sun was settling in the west and the Opera House began to glow, it was time to really get the party started. Before Shelley could say “Get your sparkle on!” Dan took centre stage as lead vocalist for a Love Shack opener and stayed there for most of the night really. Who would have thought . . . Dan + wine + music + party lights = bring it on! It wasn’t all about Dan letting lose though. We had plenty of quality vocal support from his backup team in Sim, Shelley, Alan and Darryl.

As the night wore on, others were slowly drawn to the dance floor like a chrissie beetle to a porch light in summer – either by nervous curiosity or natural instinct. It was anything goes that night though . . . we had some jumping, stomping, butt wiggling, shimmying, jazz hands, air guitar, moshing and some unique ‘undiscovered’ styles. Alok and Narayan (our twinkle toes twosome) totally owned that dance floor and showed us all that when you have rhythm – you have it all over!

By the end of the night, most of the dancing crew were either legless or shoeless. Except for Arch and Bron of course who soldiered through the pain of 3” heels so they could still engage in conversation with the tall people. When it was time to call it a night, Rob eventually surfaced from his secret nook close to the bar and we thought we’d lost Ian for a bit but eventually found him snuggled up on the corner lounge trying to sneak a quiet nigh nigh. It had been a long day.

No doubt, Sunday served up some very foggy heads and tender feet. A little birdie told me Ian and Darryl spent the next couple of days reflecting on what they could actually remember of the night and they’ve both made a pact not to “come in hot!” to a Sydney Christmas party ever again!

Until next year team Sydney. Looking forward to dusting off those dancing shoes again in 2017!





Melbourne’s Christmas party 2016

Let’s just say it wasn’t just a big night, it was a big day as well.  The IMA 2016 Christmas party officially started at 4pm with kids and families invited to join us at Luna Park for an afternoon of rides and activities.  This morphed into the late afternoon pre-party drinks, to be closely followed by the party official itself.  (Still all within Luna Park) It was great to see all the service awards given out.  For a company so (relatively) young still, the number of 3 and 5 year awards was stunning.  Whilst Sunday morning may have been a challenge for some, the Saturday night was a great one to reflect on the strides forward IMA has taken and the successes of all our consultants.  Merry Christmas all (yes we understand it is only December tomorrow, but we got in early!)

screen-shot-2016-11-30-at-9-40-43-am screen-shot-2016-11-30-at-9-40-17-am screen-shot-2016-11-30-at-9-40-02-am screen-shot-2016-11-30-at-9-39-50-am screen-shot-2016-11-30-at-9-39-41-am screen-shot-2016-11-30-at-9-39-19-am screen-shot-2016-11-30-at-9-38-56-am screen-shot-2016-11-30-at-9-38-45-am screen-shot-2016-11-30-at-9-38-20-am screen-shot-2016-11-30-at-9-38-12-am screen-shot-2016-11-30-at-9-38-03-am screen-shot-2016-11-30-at-9-37-54-am screen-shot-2016-11-30-at-9-37-39-am screen-shot-2016-11-30-at-9-37-31-am screen-shot-2016-11-30-at-9-37-15-am

Verbal Sabotage! Talking your way out of an interview.


A job interview is not a competition to ‘win’ the conversation.

A job interview is a ‘conversation’ between a job applicant and hiring manager/employer which is conducted to evaluate whether the applicant should be hired. It’s a conversation with a ‘purpose’ and not something that can be fully covered in “The 10 Most Common Interview Questions’ that you’ve most likely found online. Performing well in a job interview requires the ability to listen and respond appropriately. It’s not about all the skills you have or all the accomplishments you’ve had throughout your entire career. It’s about that specific job and the unique skills/attributes you have that match the role. Questions will be asked that are unique to that role and many great candidates blow their chances because they never listened to what was really being asked. Instead, they’ve spent 30 minutes in a one-sided conversation and literally talked themselves out of a job.

It’s an even playing field in an interview when it comes down to listening. Someone far less experienced who listens really well and answers the questions concisely will outshine any other candidate who over talks and doesn’t answer the questions properly. And even the most manicured responses can have a major flaw – they’re just too long and the audience has drifted off.

Listening is a more powerful tool than talking

Listening isn’t the same as hearing. Hearing refers to the sounds that you hear. Listening requires focus and means paying attention not only to the story, but how it is told, the use of language and voice, and how the other person uses his or her body. It’s being aware of both verbal and non-verbal messages. Your ability to listen effectively depends on the degree to which you perceive and understand these messages.

In a job interview, take you time to listen to what is being said. If the interviewer asks you to talk them through an example of when you’ve overcome a major challenge on a project, think about an appropriate example and answer the question concisely. Don’t take this as your cue to rattle off your well-rehearsed checklist of skills in the hope you’ll impress them before your time is up. It’s all totally irrelevant if you haven’t answered the question in the first place.

“The most basic and powerful way to connect to another person is to listen. Just listen. Perhaps the most important thing we ever give each other is our attention.” – Rachel Naomi Remen

Are you unaware or simply just nervous?

Sometimes candidates are so nervous or absorbed in their own conversation that they fail to notice the interviewer has drifted off. Here are some visual clues that you’ve lost your audience:

  • The interviewer isn’t looking at you, they’re not interjecting or contributing to the conversation. They’re preoccupied doing something else other than listening to you.
  • They don’t notice when you’ve stopped talking and you catch them by surprise when you stop talking.
  • There are long periods where the interviewer doesn’t say anything. This usually means they’ve tuned out and are most likely plotting ways to politely interrupt you. You can bet they’re also crossing their fingers under the table that the answer to “Do you have any more questions?” will be “No”.

Getting the balance right

Let’s concentrate on the basics. Firstly (and most importantly), understand the role you’re interviewing for. Secondly, learn about the company and the people who are interviewing you and thirdly, think of your strongest examples that demonstrate your suitability. The interviewer’s aim is to gauge your fit so really LISTEN to the questions they ask. Great interviewers have subtle ways of extracting details from you by asking very specific questions, usually based around some key performance criteria. If you go off track with your answers (or never actually get ON the track in the first place), it’s impossible for them to obtain the information they need to make an informed decision. You only have 30-45 minutes to showcase your suitability so take the lead from the person asking the questions. You have two ears and one mouth so the obvious balance is to “listen twice as much as you speak”.

Deliver a Solution Not a Project: What To Look For!

Have you ever been assigned to a client who had the budget approved, the solution identified, and the project initiated, and you were requested to manage the project? Have you ever worked on a project where you understood that the scope of the solution should have covered more than what the client had planned for? Have you joined a project only to find that key stakeholders are missing? How more hard could it be to manage a project without being in full control of its elements?

It reminds me of some statistics I came across a while ago. Being a BA/PM consultant becomes a real challenge when you know that you have only a 64% chance of successfully delivering your projects, according to PMI’s 2015 report Pulse of the Profession®: Capturing the Value of Project Management.

But why after all the maturity that took place in the project management and business analysis fields that projects still fail? I argue that many of the PMs and BAs who were sampled in the report are expert in their fields. This is clearly inferred from the same report where it shows that more than 60% of the surveyed organisations already fully understand value of project management, actively engage sponsors, and possess high alignment of projects to strategy. These organisations are expected to hire top notch BA/PMs and ensure continuous development of their resources.

If even expert BAs/PMs fail, then why there are some who managed to distinguish themselves from the rest of the crowd and associate the word “Great” or “Successful” to their title? Do they have the “magic wand” that turns any project they work on into a success story, or do they manage to see things other professionals are not able to, and manage to save themselves from losing the case? I am inclined to bias towards the second probability for obvious reasons 🙂


Let’s have a deeper look into why projects fail and see what gaps have these great professionals managed to bridge. Statistics show that 47% of failed projects are a result of poor requirements management, according to PMI’s Pulse of the Profession: Requirements Management — A Core Competency for Project and Program Success.

Being an expert BA/PM will most probably grant you 64% of the success you need, but focusing on requirement management could increase your chances to 81%. This means you need to focus on factors that lie somewhere outside the boundaries of the simple project management realm. Yes! Outside the boundary of the project. Managing and controlling these outer factors is, in my opinion, the key to succeed in most of your projects.

But why to look outside the project? isn’t requirement management already a part of the project? Well, yes and no. Requirement management starts way before the project starts and forms the basis on which projects initiates, and this is where the risk comes from. Remember the scenario discussed at the beginning?

Back to the consultancy world, you usually join the client when the project is kicked off and you are required to deliver it “successfully”. This means that some sort of requirement management effort has already been taken place, and you have no control on the level of quality done to identify the business requirements behind the project and the value this initiative is expected to bring to the organisation.

If you proceed with your project as initially planned, you put your destiny on the hand of anonymous stakeholders who promoted an idea, formulated a project, and put you in front of the cannon. What happens if they have laid the wrong foundation for your project? For example, what if the client:
● Mixes desires with needs, and formulated a project around these desires without real business need?
● Articulates solutions as requirements and expect them to be delivered without proper assessment of their validity and effectiveness?
● Agreed to a solution that is not linked to business objectives?
● Has no business case or enough support from within the organisation?

If you don’t know where you’re going, any road will get you there.” – Lewis Carroll

In these cases, a project manager would be able to deliver the project according to the stated requirements but would put himself a potential prey to the 36% of failed projects and some reasons for that would be:

● In reality, projects are judged by the value they deliver to business rather than to what extent they match stated requirements.
● The ones who evaluate the project success are not necessarily the sponsor who initiated the project. These stakeholders might not have been identified as key stakeholders.
● The project delivers the intended value but it is not enough to realise the real benefit to the organisation.


The key to “great” project management and business analysis work is to meet the expectation, and by expectation I mean organisation’s one and not merely the sponsor’s. Remember that great BAs/PMs need to align project objectives to organisational ones, and this what grant them sustainability and success.

To meet expectation, you need to find and work on a complete solution that resolves client’s underlying problem, and not only smooths the symptoms that appear on the surface. Delivering the “stated” project might not give you the result you need because, at the end, the deliverables will be part of the new organisation’s capabilities, and you wouldn’t be sure if someone has already verified whether such deliverables would fit in the organisation smoothly.


Successful projects manage to synergise deliverables with organisations’ environment. This means that project needs to take into account the organisation’s readiness to implement the solution successfully, integrate it into the day-2-day operations, and grant enough support to sustain its existence and realise its benefits.

This means that BAs/PMs should seek solutions that consist of some or all of the following:


Assess what and how technology is used and promoted inside the organisation. Verify that existing technology doesn’t fulfil the functionality requested. See if the new solution is in alignment to the technologies existing within the environment. Check contractual agreements and make sure the new solution is not limiting the organisation in expanding its business. Check if the technology used doesn’t need a change in other areas, like processes and organisational structuring.


Assess what skill set is available within the organisation and whether it is enough to guarantee project success. Assess what development areas should be addressed to ensure value realisation. Verify that enough resources are available to get the job done. Assess how processes are setup around the solution and whether such processes are efficient. Process re-engineering is gold mine for boosting operational efficiency.

Organisational restructuring can also be part of a solution. Changing the way people are structured throughout the organisation could help streamline operations, increase efficiency, and ensure the right people own the right solution components.


Assess how internal culture impacts the work carried within the organisation. Understand how formal/informal politics/power impact and drive decision-making. Locate informal influencers and make sure they are content, if not satisfied, with your solution.

If a solution doesn’t require a cultural change, understanding how culture impacts the daily operations helps getting the right people engaged, and keeping the project on focus. Granting buy-in to your deliverables is key to project success.


When you join a project, don’t settle for what you are told to do. Maybe you are obliged to abide by the scope of the contract, but this should not hinder you from being on watch for what could cripple your project, continuously revising the givens and making sure what you are delivering constitutes a “complete solution”.

Be in search for external factors that grant you success. Influence decision makers to take corrective measures. If you are not able to change the course of the project, at least you know what you are missing, and maybe you could influence decision makers on the right time. Keeping key stakeholders aware of what a complete solution should be puts them on the same boat with you.

Don’t lose focus of the critical solution components: Technology, People, & Culture.

This time I highlight “what” I think you need to look for if you want to increase your chances of getting it right, wait for the next blog where I will discuss “why” and “how” looking into the bigger picture increases your chances of delivering great projects.

Wael BassionyPassionate about project management and the challenges faced by project managers. Over the last 16 years, Wael assumed several positions in IT and Telecom sectors, with specialisation in business analysis, project management, technical architecture, and leadership. He has hands-on experience in managing diverse types of projects, from small, short-term, to MM$, strategic ones. He holds a Master’s degree in Computing, a Master’s degree in Business Administration, and a number of technical certifications like PMP, CBAP, and ITIL.

Sydney Social Club – Hard Rock Cafe and Laser Tag (October 2016)

Another great night with the Sydney team, expertly organised by Divya and her right-hand man Arbie! For some ‘pre-combat’ courage and fuel we started off at The Hard Rock Cafe which didn’t disappoint. Great atmosphere, location, food . . . and of course, the company was exceptional! Immediately Anu took centre stage and placed himself right at the centre of the food action, devouring the BBQ chicken wings, pulled pork buns and vegetarian delights. There was plenty of food for everyone (even a delicious gift for the homeless man Amu!).img_0345

We were all pumped for laser tag although the majority of the team really had no idea what they were in for. But that didn’t matter – we collectively were ready for anything. The pre-dinner wines, beers and soft drinks helped with that.

So we’re all suited up with flashing vests and plastic laser guns listening to the host explain all the rules . . . and then something just came over Boris. He had his poker face on and started looking all ‘Arnie like’. I was scared but thankfully I was on Boris’ team. Boris was clearly on a mission and off we all scampered in to dark maze of the laser room.fb9fb7bb-d4e1-49a3-aaa4-f057475613d0

Some people take to combat/hide and seek naturally . . . and others, well, unfortunately they just don’t. Poor Alan, bless his 10ft long legs, was a big target. “Duck Alan, Duck”. Arch was lost most of the night but we were able to find her easy enough by following the trail of laughter. Others just wandered aimlessly shooting at their own team members. Maybe they would get it by Game 2 . . .

Then there were the ‘natural born killers’. Power couple Arbie and Lavinia proved that love = I’m going to take you DOWN!! Boris in his Terminator transformation, effortlessly disarmed the unsuspecting from a secret vantage point as they fumbled around the dark maze. Darrell was on a mission. What that mission was, I don’t even think Darrell knew. Mahesh was also a bit of a dark horse. All ‘cool as a cucumber’ like. Go the MULA. Mahesh – Ultimate Laser Assassin

So 5 kilos lighter, we exited the maze and had a good old laugh at the score board. Some of us improved in Game 2 by perfecting our strategy, but others were doomed to the bottom of the table. Good practice for next time though Sydney teamers and we all had a blast!

Hasta la vista!




Additional Budget? How to spend it wisely…

MONEY- this is the word that rings first when any task has to be accomplished.
Often, organisations allocate budget for projects that are considered as business enablers or enforced as mandatory changes to be implemented for that year. It’s a dream for the management that there is more money allocated to the project than what is required to achieve the project outcome. Such dreams comes true when the board realises there is money that is not yet spent for the financial year and authorise the additional money to be spent for any projects or initiatives.

It sounds easy to spend money but it’s always a challenge to spend additional money constructively to bring in positive outcomes. Spending additional budget is yet another project which requires evaluation of options, estimation, good planning and successful execution.

While additional budget is available, we also need to be mindful that it has to be spent to the benefit of the sponsor. At the same time, all stakeholders would expect the fund to be spent wisely and effectively. While there are numerous options to constructively spend additional budget, there are few options which benefits project, team and sponsors equally.

1. Invest on activities that benefit the sponsor such as Process Improvement
There is always a room for improvement in any organisation. We identify a list of improvements and in most cases, those initiatives don’t get mobilised either due to lack of funding or due to other high priority activities in the pipeline. When money is available for initiatives, it’s good to start implementing those improvements that would benefit the organisation. On implementing improvements, the organisation would realise the benefits in near future or upcoming projects and would result in a satisfactory outcome both for the sponsors and the project and eventually it would be a good learning experience for the team.

2. Identify potential future projects and invest the fund to do the initial assessment for the potential projects
Most of the projects limit their scope to what can be achieved with the allocated funding and within the expected timeframe. The tasks that are deferred for the future eventually become the scope for the a new project. Additional budget available in the current project can be used to do the initial assessment of those deferred tasks which serves as the key input to initiate the next phase.

3. Onboard additional staff and invest on up-skilling the team members and at the same time the team can contribute to the project outcome
Knowledge of a business process and technology is an asset for any organisation. On-boarding additional resources and up-skilling them during the project journey has a two fold benefit; the new member can contribute to the project and at the same time the resource can be trained in the business process which can be leveraged in the future projects.

4. Allocate some fund for rewards and recognitions
A motivated team brings in remarkable results and timely recognition and rewards ensures that the team is motivated to continue to do their good work. Some of the additional budget can be spent for rewards and recognitions while will keep up the morale within the team.

5. Organise team building activities
Teamwork is one of the top soft skills that is required to have a healthy and positive working environment. Team collaboration helps to achieve the project objectives efficiently. Team events provide an environment for the staff to interact and socialise with their colleagues out of their daily work. This helps to build a more friendly work environment, which eventually results in better project outcomes.

6. To retain skilled resources until start of next assignment.
To spend the additional funding inline with the project objectives is a tricky challenge in a scenario where you may already have enough funds to meet the project commitments. If there is a possibility to carry forward the remaining fund to the next phase of the project then the fund can be utilised to continue the core skilled team members if there is a visibility of any upcoming projects where their skills are required. This in-between time, while the next phase is yet to start, can be a good reason for the team to document their learning and prepare knowledge artefacts that can be used to train new members in future.

Ideas to spend money are never ending but at the end of the day, the money has to be spent constructively and wisely. The key success to spending money is to first get the ideas open to the stakeholders and get the buy-in from everyone involved on the option chosen to spend the additional budget. The task doesn’t end in just finalising the option. The challenge is to execute the budget plan successfully, monitoring and tracking throughout the journey and to achieve a positive closure by accomplishing the expected outcome within the budget. Also ROI and benefits has to be evaluated before starting the budget plan.

Money and business are in a cycle, spend money to improve business and improved business gives back the money. It sounds easy, isn’t it? But we all know its not in reality. So Spend Smart!

Gayathri Ramamoorthy – Gayathri is a Project Manager who joined IMA recently and has over 14 years of experience in IT industry. She has been working in IT projects in diverse domains, which includes Manufacturing, Telecom, Chemical and Food Process Industry, Financial Services. She spends her leisure time with her daughter playing interesting kids games. She has now started to explore the experience of blogging and this is her first attempt towards the blog journey.

How to be influential to your stakeholders – Part II (A PM’s perspective)

After reading the blog from Supriya (see it here), I was inspired to write a blog to discuss influencing leadership (or decision makers/ senior stakeholders) from a Project Manager’s perspective.
The way I see it, Leadership is one of the most valued assets in the corporate world. As such, influencing is one of the important aspects or subsets of leadership.

Before understanding how to influence let’s try and understand what influence really means.

Influence is commonly perceived as: something hypnotic, something about having an impact on the behaviour or change in thinking. It does indeed to a certain degree. But in the real world (read corporate world) its relevance is more about having a common goal, having a common purpose; it’s about having a strong buy-in and support for a common “motive”.

Influencing is a process of having your stakeholders acknowledge, appreciate and eventually align with the reasons to have a successful endeavour/project and the way we achieve that. It becomes imperative for a Project Manager to focus on arguably the most Critical Knowledge Area called “Stakeholder Management” in PMBOK.

1) It all starts here. BIG PICTURE. Why are we doing this project? How does it align with the organisation mission/vision? Believe it or not! “Implicit Assumptions” are made even at this stage. Elicit information from the sponsor/project owner. It all starts here.

2) Identifying the stakeholders is the key here. Consolidating a correct and complete list of ALL the stakeholders, their roles, decision making authority and their stake within the project/endeavour is the activity that needs to be taken up in the “very beginning”. Importance of this activity is often overlooked.

3) Understand the expectations. The next step is to identify what is the outcome each stakeholder expects and “how” they expect it to happen. This is the step where the Project Manager’s communications skills play a VITAL role.

The Project Manager needs to be a STRONG listener and also needs to exhibit his/her skills in eliciting the information. This indeed is a challenging activity especially if the Project Manager is unfamiliar with the environment (which is mostly the case in consulting organisations), does not understand the business terminologies (read jargon☺) and does not have a clear idea about the organisation structure. Hard truth is not everyone will open up. The art here is to LISTEN to the stuff that is not being said.

Understanding the organisation structure and reporting structure (both dotted and solid line) within the stakeholders is of utmost importance. This may help you to identify points of contact rather than chasing multiple stakeholders during the project lifecycle. This will clearly help to understand the right way of “getting things done”.

Though it is expected that the Project Manager needs to address as many questions as possible; it may sometimes be frustrating for the stakeholders answering questions they perceive to be trivial. The skill lies in striking out exact balance between understanding the detail enough to facilitate further activities BUT not going overboard. Here’s a link providing some insights on “How to ask effective questions”?

Influence and be ready to be influenced. Yes you got it right! Be absolutely open and ready to analyse new ideas, methodologies and ways of working.

Do it in closed rooms or coffee shops or while having your afternoon snacks. Do not trust your brain. Take your notes. That way you need not to be stressed while you catch up with a friend for the evening beer or two! ☺

4) Analyse. Good Morning. Make/Buy a big cup of coffee. Yes I will prefer this to start in the morning ONLY AFTER a cup of coffee! ☺

Check your notes. Analyse.

a) Identify if there are any conflicting expectations.
b) Identify what “ways” have been suggested. Try to understand the underlying reason (if you did not get an opportunity to do that in the previous step).
c) Validate your expected outcomes.
d) Analyse and identify the best ways or devise your own ways considering the impacts on the outcomes.
e) Document your suggestions and make sure the reasons are validated when you choose any particular way of working/methodology/expected outcomes.
f) Have your stakeholders engagement assessment matrix and Power Grid Matrix. Handy tools for stakeholder management.

5) Iterate. It may not all happen in one go. You may need to iterate Step 1 to 4.

6) Influence. Yes! Your hard work has paid off. You have all the data and a strong reasoning behind what, why and how you suggest doing it.

You have developed significant buy-in from most of the stakeholders and you have been successful in setting the appropriate expectations.

Things will start to MOVE for you. Of course they do!

The BIG thing you achieved is proactively addressing the issues that may have potentially surfaced much later in the project possibly leading to a SIGNIFICANT NEGATIVE IMPACT on the triple constraints of the project. You can sleep well!

Stating the obvious: Integrity and “Walking your Talk” goes a long way in having the FIRST DIRECT INFLUENCE on the people you are working with!

Here’s a bit about Abhijit. He has been in the IT industry for 18 years and has been fortunate enough to work in different areas like Education, Banking, Health Care, Telecom and Environment & Heritage. His career has seen him have the opportunity to work in different roles like a Developer, Architect, Business Analysis, Team Leader and Project Management. Highly experienced working with cross cultural and distributed teams in different countries across Asia, Europe and now in Australia. Abhijit thoroughly enjoys working in handling complex, challenging and demanding projects. He loves to travel and is a self-proclaimed foodie. Abhijit loves playing with his daughter and facing her tough questions. Occasionally he tries his hand at Table Tennis and badminton on and off.

How to be influential with senior clients/stakeholders – Part 1 (A BA’s perspective)

Stakeholder management is one of the important aspects of business analysis. In this blog, I want to share my learning on how to be influential with senior clients/stakeholders as a business analyst. I usually follow the “Five Ws and One H” format, which forms the basis of “Problem Solving”, but have modified these questions to fit the topic.

  1. Who is a senior stakeholder?

Stakeholders are people, groups, vendors or organisation who participate in the projects and have different levels of involvement and interests. They also are likely to be impacted because of the project. Senior stakeholders are those who possess the highest authority in the project environment.

  1. Where to find them?

Stakeholders can be in the office, on the field, in the factory or anywhere else. When a business analyst is assigned to the project, he /she needs to identify the stakeholders and conduct stakeholder analysis. The BA has to use multiple ways to find them.

Get the list of stakeholders involved in the project from the manager or supervisor. Talk with people to find the decision-making authorities, executives, third parties and end users. Also in IT projects, there are instances where the software systems interact with other software systems and hence it becomes necessary to find who owns these and check if they are impacted by the new initiative.

A simple method to capture this information is via Stakeholder Analysis Matrix. This matrix should contain all the required details about stakeholders involved in the project. It helps in identifying senior stakeholders and estimating their levels of interest based on how it would impact them. That will in turn help to prepare before interacting with them.



  1. When to influence the senior stakeholders?

Influencing stakeholders from all levels (junior till senior) is an ongoing activity, which starts from day one of the project. Early start to this activity is always beneficial to the project.

  1. Why is it needed to influence them?

Business analysis is a critical part of a software project. In complex projects with diverse stakeholders, their different motivations might affect the delivery of the project. The BA needs to quickly resolve all types of issues and lead the way. The BA also has to keep them interested. However BAs don’t have any formal authority. Hence they must be influential enough to exercise that power informally.

  1. How to be influential with senior stakeholders?

Now to successfully influence the senior stakeholders, I follow the below techniques:

  • Communication techniques

Get to know how they want to be communicated. Some might prefer one to one meetings, emails or even phone calls. Understand which method would help. Prior to your interactions, do the homework, anticipate how the discussion is going to be and be prepared. Listen to them, take notes, analyse, be clear in communication and show willingness to act upon the points communicated by them. Ensure that desired response is received at the end from the stakeholders.

  • Focus on high-level details and avoid technical jargons

Senior stakeholders might not understand or be interested in technical details involved in the project. It is always good to give them the high level details and if they require more details then provide them. Focus on knowledge and facts.

  • Be confident and trustworthy

Be confident and show interest at all times and in all situations. There might be instances where stakeholder might come up to you and ask you for information. Hence keep your data handy. Senior people appreciate if you provide counter arguments, differ in opinions or are frank to tell that you do not have sufficient knowledge to answer right away. It makes them believe that you mean what you say. Provide evidence as to why your approach is better one if asked. Keep communications channels open, listen to what they say and be transparent. Always keep them informed on the status of the project, risks in the project, deadlines and results. This way it helps them to trust you.

  • Deliver commitments

Take responsibility of the project and stick to what has been committed. Show results to prove your competence. This shows that you care about the stakeholders and care about delivering project successfully.

  1. What are the benefits of being influential?
  • Benefits to the stakeholders: At the end of the project, stakeholders are satisfied and their requirements are implemented. They get what they need, have positive experience with project delivery and they get business value in terms of results.
  • Benefits to the business analyst: Benefits are on both personal and professional ends. It helps BA to perform better and it boosts confidence, builds credibility and leadership qualities. Further helps in professional success by creating positive relationship with the stakeholders and in creating brand value.


Finally, I would say that influencing senior people would require a planned approach and but keeping in mind “Keep it Simple and Sincere” principle doesn’t make this look so difficult.


Supriya Joshi BioSupriya has recently joined IMA as a business analyst. She is an IT professional with more than 7 years of experience and has worked on banking, automobile and healthcare domain projects. She has worked with diverse stakeholders from several countries and demonstrated good business analysis skills. She possesses good analytical, problem solving, and communication skills; always strives to deliver quality products. She likes travelling and exploring new places, cooking and spending time with family.

Think before you Agile..


What follows are my personal experiences and thoughts based on a recent contract role that I did as a Project Manager of an Agile project.

Agile has been a buzz word for quite some time now and I think it’s safe to say that it’s caught on as a fashion statement as far as project methodologies go. Nowadays most of the job adverts ask for agile experience, which I assume is a direct indicator of most projects wanting to go the agile way. I have attended an interview where the hiring manager, looking at my profile said something like ‘I feel outdated and have been thinking of going agile with my project’ which in fact was a multi-year network upgrade project, one of the last projects in the world I would think of making Agile.

My project was a long term (2 years) development project and the project team involved 7 squads working on a fortnightly sprint based development model. We followed Agile ritualistically. We breathed agile so to speak. Where I stand now, I believe that agile, in its purest form, may not be appropriate for most of the long running (multi-year) projects around.

Here are some tips I’ve picked up in my experience to-date.

Agile Must Haves:


However you try to coat it, Agile depends heavily on making documentation lean and on demand. This has some detrimental impacts in the long run. If you have a project running for a long duration, or a project which is done and dusted but the go live is delayed and the team had to be dismembered and re-convened (with different set of contractors) later . Nobody would have a clear end to end view of the architecture, requirements, design implemented, standards used etc. Thus the need to focus on the long term, even when the sprints are of 2 weekly duration. Figure out what are the documents that an operation team would require to maintain the application, or a new set of contractors would need if they were to re-engineer the solution for whatever reason. System appreciation document, Requirements document, Requirements Traceability documents to list a few. Effort needs to be set apart and planned for documentation during each iteration or at regular intervals say every 4th iteration.

User Stories:

There is an argument that user stories provide traceability in agile projects. But I haven’t found that effective. User stories would be sliced pieces of bits and pieces of functionality which are created to fit into the effort available in a sprint doable by a developer, testable by a tester. But no group of user stories would clearly depict the requirements in a clear and understandable manner in the long run. Hence go for a tool like JAMA for putting in requirements. You need to establish a clear heirarchy of functional requirements and a process as to how and under what sub requirement would a user story of a particular type and function be added. Establish the skeletal process upfront before you write your first user story. We got into a mess as the skeletal structure and the processes were not set upfront and each Scrum Master who came on board went their own way in documenting requirements.


Refactoring is the next topic that needs attention. The need to get going with the next set of requirements, along with the need to be agile and deliver at very short intervals leads to a lot of disjointed coding practices and deviations from the initial design architecture standards. More often than not you would tend to cut corners to ensure we deliver the requirements on time for the iteration. There is an unavoidable need to have a refactoring sprint planned regularly. If it could be afforded, you could have a separate squad consisting of the architect and a developer working together who pick up what has gone into the previous iteration. This squad then reviews, corrects and refactors code where required regularly. Another idea is that it can be a sprint planned for all/some of the squads every 2 months or so where they spend (say) 1 week of their time in refactoring and tidying up what has already gone in. In the second model it is imperative that some watchdog like the architect or a senior developer keep a note of what are the corners that were cut, deviations that were done, either in consultation with or whatever is found through reviews.

Work/life Balance

Agile gives a real good work life balance for employees. It’s perfect from a developer or a tester’s perspective. You commit to what you can do and go ahead do that.

It’s perfect in all the other ways that we all know about like, being able to cater to the customers immediate needs, providing a working software at regular intervals which the customer can look and feel and modify his requirements accordingly to.

Agile keeps the enthusiasm level up there or thereabouts always. It is great to have frequent sense of achievement, release of pressure, re planning and re estimation, recharging of batteries.

A Physical Agile Board:

Always have a physical agile board unless you have a big and wide screen monitor/smart board which is life like. The sense of physically moving tasks from one stage to another cannot be replaced.

Have a ‘graveyard’ where you would move the completed tasks and stories. If possible get different squads to use different colours or may be different colours for different types of tasks (one for dev and one for Test maybe) this would help to create some nice and creative patterns on the graveyard which through a time-lapse video would make us all proud as a work of art and provide an ongoing sense of achievement.



Agile Pitfalls:


Agile is for teams involving good to expert level developers and testers. New members must be drafted in gradually, and drafted in only when then they are very close to 100% ramped up. New team members or those who are not well versed with the technology in-use, liquidate the effectiveness of agile methodology. When such a member joins, for quite a few iterations at least the team’s velocity estimates go low and so does the productivity. Agile teams are like bullet trains. You can’t attach a cargo van at the end of it and expect it to run at the same pace. It can be very detrimental. This is one of the reasons I feel, why agile is not good for a long running project where you, more often than not, would have churn and developers and testers move in and out frequently or in organizations where resources are pulled into different projects or operational activities at various times.

In an agile project the timeline OR the scope can remain constant. Both cannot. Due to the inherent nature of agile, scope gets swapped in and out, functionality requirements keep changing everything moves around between iterations.

Stakeholder Management:

Ensure that you engage and educate the stakeholders on what they are getting into. It so happened in one of my projects that towards the end of the project, (mainly due to some internal politics between the concerned departments within the company) the agility and its rules were forgotten and the business put a wooden foot forward saying the scope is non-negotiable and so is the time-to-market. Hence all the remaining scope in the backlog became indispensable. This same backlog was always thought of as a priority list (as it should be) which would be tackled in the right order and it would be the product owners responsibility too to ensure that he gets the most important features in the time remaining till the project go live. So now we had a situation where the product owner who was all agile and happy to add in and chop off requirements as he wished suddenly went backstage and there we had the business director standing on top of us with a ‘my way or highway’ attitude.

Agile Non-Negotiables:

What the above scenario teaches me is that even though we run an agile project, do 2 things. Educate / coach your stakeholders on how agile works and what it means, with respect to overall scope and timelines. Secondly, keep yourselves covered by always probing and getting as much requirements (even at a high level) listed upfront, high level planning poker done for all the requirements , add your buffers and keep the forecast with respect to scope also highlighted in your weekly reports. What I mean is, if there was a new chunk of work that came in to the backlog which suddenly became priority for the product owner, show clearly by means of trend graphs how the overall scope has increased and how that impacts timelines if all the requirements were to be completed.

You might say “we all do that!” Yes but still ensure that every week the view of how the overall picture looks with regards to scope is provided to all stakeholders. The product owner shouldn’t be able to shrug off the accountability of getting what is required in the time that is allocated.

Particular mention needs to be made of some product owners who, on seeing that the velocity of the squad is really good, tries to get it in more thrills and frills wherein that high velocity should be used to tackle the important features first and then return to the thrills if time permits. Keep a tab on the prioritization thought process of your product owner at all times.

Squad Management:

When you have multiple agile squads, each runs with a different velocity of course as each squad has a different way of story pointing and different levels of productivity too. Thus, when preparing project plans you need to ensure that you take a reasonable and probable average velocity into account. If you are starting a new project with new squads who haven’t been together before then all you can do is a reasonable guess I believe. But ensure that you do a most likely, worst case, best case analysis and provide forecasts accordingly.

Agile Pitfalls: The next bit, though a bit sensitive to talk about is worth the mention. Agile teams can grow to be very sentimental and moody. They need to be nurtured with care and love. At times all that care and love can create a monster. They become a collective unit and conspire to put blockers where there are workarounds, give out considerably higher story points than is appropriate, can decide to delay a few activities so that the stretch goal needn’t be brought in to the current iteration even though there is spare time available, give out higher story points and ensure that there is enough buffer to compensate for less than 100% effort. All this can happen even when teams aren’t facing new challenges regularly. So one way of tackling this is to do a close monitoring of the work that each member is doing, even at the risk of going against one of the concepts of Agile which is to have full belief in the team and its capabilities. You could do this being less conspicuous by catching up with team members offline and not in a formal team meeting environment or at her or his desk. You might even want to swap team members without affecting the structure too much at the same time. This reduces chances of such behavioural patterns developing.


Other things to consider.



We once had a security hackathon which was basically a 2 hour period wherein all the developers and testers attached the application and tried to crack into secure data. It did bring out quite a few security vulnerabilities, which are part of the often forgotten and often non-written non-functional requirements. This is a highly recommended practice.

Getting the squads together to engage in some agile games is another way of making it fun at work while indulging in some team building activities. You’ll get a truckload of games online which you could try out for your squads. Most of my team really liked whenever we had them.



Backlog is very volatile bucket so how do you actually depict anything meaningful to the stakeholders on how and when would something be done. A visual representation of what feature was developed when we had what we called a Sprint pipeline plot. Which was an excel sheet which showed blocks of work that would be covered by each squad and around when.

Also consider how useful this would be in a situation where you have 5+ squads (like we had 7) and you have a year-long project to run. Scope might keep getting added to a particular module and might get culled in some others, but with this sort of visibility you can easily look at options on how you could rejig and make everything fit more like a jigsaw puzzle. It would be much easier discussion with senior stakeholders too, in order to explain how agile you are and how confident you still are in meeting the project goals.


Screen Shot 2016-08-11 at 11.41.50 AM
We did an EVM (Earned Value Management) plot. Keeping in mind various aspects like the most likely, worst case and best case average velocity of the sum of all squads.Financial management

The total scope that we had to cover in terms of story points. This was based on the initial very high level planning poker where we got the total number of story points that needed to be covered. Here again we did a best and worst case. It’s imperative that we do a reality check a few times through the project to revalidate the total number of story points that forms the scope. Please ensure that when you do this exercise you do take into account time that needs to be spent on stuff other than development, testing and deployment, I can think of research work, tech spikes, maybe a cloud deployment etc. which may not be part of a module you work in, may not be part of the discussions and work that you do with the product owner but are necessary for the software to be released. I could write a separate blog on how to prepare EVM graphs for an agile project. That’s an elaborate topic in itself. May be I will do it one of these days and provide some examples on how to go about it.


By: Nikhil Prabhakar 

Nikhil is a project manager who has recently joined IMA who comes with a management background in Applications development, Service Delivery, Transformations and Transitions and has worked with a diverse set of customers across the globe.
He has just been promoted from ‘forever wanting to write about his experiences’ to ‘having his first blog published’. Nikhil is an avid soccer fan and is’nt shy in proclaiming his support for Arsenal FC