Skip to main content

Author: Brad Egeland

5 Things Your Project Customer Assumes You Know






The Business Analyst and Project Manager should be focused on the success of the engagements they are leading. The Business Analyst is leading a team of skilled resources who should have one common goal in mind – to roll out a successful solution to the project client.

Do we know everything? No. Do we know everything about the project we are leading and about what we are supposed to be doing? We should! We aspire to, but there are likely a few things missing along the way. We learn as we go along. Do we know what our customer is always thinking? What they think about our performance or how we are managing them, the team and ourselves? No.

Well, I’m hopefully going to close that knowledge gap a little.

Here are my top five things that your project customer assumes, hopes or wishes you knew about them and the project you are leading for them.

You’re the expert, not them.

You are the skilled Business Analyst or consultant. You and the Project Manager are the individuals leading the team with the skill set needed to identify, design, and develop their solution. If they had that skill set or the time to do it, they wouldn’t need you.


{module ad 300×100 Large mobile}


Understand that you are the expert. The client knows that and wants you in that role. They may annoy you, demand things, they may even seem like they are getting in your way or trying to take over, but really, at the end of the day, they will be the most satisfied and confident if you are in control, take the lead, and direct them.

Money is very important to them.

We all must answer to someone higher up with respect to budget, profit margin, and overall financial health of the work we are performing. It works the same way for the project sponsor.

The project customer cares about the money they are spending on the project, and they want to feel comfortable that you are spending it wisely. Therefore, they expect this to be reflected in any weekly status reporting and dashboard view in terms of actions, work progress, and often budget analysis.

They have a day job.

They want you to know that while the project is very important to them and may be an important part of their career, they also have a day job. Rarely is the project you are working on their only responsibility. After all, they shouldn’t have to do too much on the project because you and your team are the real experts, not them, right?

Related Article: Getting the Project Client to Focus on Requirements

They have other tasks to perform, bosses to report to, and even teams to lead. So they might not always be available with the information or decisions you need.

Keep them engaged, give them time, and be patient. And take charge and make good decisions in their absence.

They do not know how to test very well.

Your client may not like to say it, and they may not show it, but it is often the case that project customers do not know how to test very well. And they certainly won’t be experienced on this new solution you are planning to implement. Help them. Don’t do it for them – that would be a conflict of interest. But you can help them with test cases and test scenarios and hold their hand through the user acceptance testing (UAT) process.

You may find yourself and some individuals on your team spending more hours before and during UAT than you had in estimated in the budget, but it’s worth it, and you’ll know to include more hours in the schedule and estimate next time.

You are not their friend.

Keep it professional, no matter how friendly or easy the communication becomes.  If you let it go too casual, you risk missing some information sharing along the way by assuming the other party may already know.

The customer may seem very comfortable with you, but you are still not their friend. They are paying for your services. Run professional meetings, continue professional conversation, and engage them like they are the project sponsor, not your friend from high school. And avoid the drinks at the bar with them after a big onsite meeting – it’s just not professional.

Summary / call for input

We do everything we can for our project customers. Lead their projects, manage the budget, engage them and try to keep them as focused and confident as possible throughout the project. But we can’t get inside their head, and they don’t tell us everything. If we could, though, these are things that I feel they would be thinking that we should know as far as what is driving their behavior and management of the process.

Remember, the Business Analysts, Project Managers and teams are the professionals hired to manage the projects. But in the end, it is the customer’s project, so keep them engaged and informed throughout. Have those periodic one-on-ones with the project sponsor to ensure that you know what they are expecting of you on each engagement and at every turn. Sometimes their expectations need to be reset, and that’s ok.

The key is never to stay out of touch with them for very long.

What about our readers? What do you think your project customers assume you know about them and the projects you plan and manage for them? What do you think they wish you realized as far as what’s important to them? What, from your experience in working with project customers and key stakeholders, would you add to this list or change about it? Please share and discuss.

Let’s Make a Deal – The Art of Project Negotiation

You’re a Business Analyst or Project Manager on a technical project. You probably realize most of the roles and hats you need to play and wear. You are a task master, a resource manager, a change agent, a master communicator, a meeting facilitator, a financial wizard, and a critical decision-maker.

And now you find out you are also a master negotiator. Yes, master negotiator. Or at least, you should be. At least, you better be ready to at least “fake it till you make it.” You may be negotiating right now on your projects and not really realizing it, but you might want to focus on where you are doing the negotiating and pinpoint what you are doing and work at improving those skills. Why? Because you will always need those negotiating skills – likely on every project that you manage to some degree – and you’ll want to continually improve in this area. Again why? Because you often need to rely on winning those rounds of negotiation in order to win on your project or keep it moving forward and keep your project customer satisfied and confident in your ability to keep the project running efficiently and on track in terms of time and budget.

Do you consider yourself a negotiator?

Whether you are a Business Analyst or Project Manager, you are negotiating from time to time on the projects that you are engaged on or managing. Do you consider yourself a negotiator? Have you been aware of these events as the projects unfold? Let’s consider what these negotiating opportunities and needs are so that we can be aware of them the next time they occur and use our negotiation skills to our maximum benefit and become even better at negotiating when we need that skill next time. Some negotiation events or opportunities we likely run into during the course of some of our projects throughout our careers are:

Negotiating for resources. Maybe you really need a top technical resource, and you can afford to put more of a part-time Project Manager or Business Analyst on the project – or one with a little less experience – because it’s a very short-term, but very complex project with a complex technical solution. You negotiate that resource acquisition to the most favorable way possible for your project, right? You look at the landscape of your resource needs and trade-off accordingly because you’re never going to get the best of the best at every project team member position anyway.

Negotiating for task assignments. You look at your resources on the project team and the tasks to which you need to assign them. When are they going to be available considering their other project commitments with other Project Managers and Business Analysts and which tasks do they love or hate. Some “don’t do windows”, so to speak. I had a contractor on my house who would do everything but hated to paint, so I found someone else to paint and he gave me a great price on all the work he loved to do. Negotiation – it gets tasks assigned and to the right people who have the right skills and love that specific work.

Negotiating for deadline dates. Sometimes deadline dates need to move, for whatever reason. Usually for the good of the project, but that doesn’t mean you won’t need to do a little negotiating with the project client to make date changes happen. As the Business Analyst, you can work with the technical team and see what functionality can be shifted around if you are doing a phased rollout on an Agile project. The key is to show the client documentation that convinces them the project won’t be at risk, and the trade-off is not going to affect them adversely. It may take some skilled negotiating, and you will have to do this from time to time. If you haven’t yet, you will.

Negotiating for project funding. When have you ever run a project that had an abundance of funding available? If additional funds are needed – if that is even an option – you may find yourself negotiating for those extra funds. Whether that’s from your senior management or the BA going to the client and explaining why the technical solution is going to cost more than originally planned – either way negotiating skills will likely come into play.

Negotiating on project change orders. Just as for additional funding, you may find yourself negotiating with the client to get needed change orders approved. Usually, this will come up as needing to give away some work for free in order to get sign-off on a needed change order that will add needed functionality to the project but also will end up costing the project client more than they originally planned to spend.

Negotiating on technology used for project solutions. Sometimes the client comes in with a technical solution in mind. In fact, the latest and greatest technology may be the entire reason the project was initiated. How that technical solution is implemented, and even the technology behind the solution may need to be changed from what the sponsor originally wanted for practical purposes or to stay withing budget and time constraints. Either way, negotiations will likely need to take place.

Summary / call for input

I realize that some of these instances just happen, and you may not have considered them negotiating points. But many times they are. And you can leverage one incident against another when necessary to get what you may really need or want on the project. You can take a less experienced tech lead resource in exchange for the top data integration specialist this time around because data integration is critical on this project but you can let the top tech lead go to another project. In the long run, you’ll be ok. There, you just negotiated. It’s often give and take – you gave, and then you took.

What about our readers? When have you had negotiating opportunities on the projects you are working on? What strategies do you employ to get the things you need and the dates you require and the funding that is critical to your project? What other negotiating opportunities would you add to my list above?

Why Everyone Needs a Business Analyst on the Project

I’m a Project Manager and a consultant.  I’ve never been a Business Analyst.  I’ve been an Application Developer, but never a Business Analyst. 

I’ve helped the Business Analyst do their job on many of my projects and the BA is usually the one that I work most closely with on the projects that I manage.  But I’ve never had sole responsibility for the business analyst function on a project.  And I truly believe that my project management success rate can be directly tied to working with some great, experienced Business Analysts on some of my most technical and complex projects.  There is no substitute, in my opinion.  I will sing their praises from the rooftops.

Why does everyone need a Business Analyst on their project?  That may be a bit of an overstatement…there are those smaller and less complex projects where a Project Manager or Business aAnalyst can likely cover both roles.  But for longer term, higher profile and more technically complex projects, I strongly suggest that both roles are absolutely necessary.  I am going to present my own five-point argument here as to why that is the case.  I welcome your thoughts and input and discussion to either support or refute this concept. 

Here are my five reasons why every (most?) projects – at least complex, technical ones –  need a Business Analyst:

1.     The Project Manager needs to focus on the project management tasks. 

There are enough administrative tasks on most projects to justify a full-time Project Manager, in my opinion.  This is especially true for longer, more complex technical projects.  In recent years, I can’t imagine not having a Business Analyst assigned to most of the projects I’ve run as they have often tended to be at least 6-12 months long and worth around $1 million with fairly complex technical solutions, interfaces, and implementations.  Asking a Project Manager to cover both roles is asking too much because managing a project like that – depending on the customer’s needs and complexity of the project – can be a full-time job.

2.     The Tech Lead needs a good liaison heading into design work on the project. 

On most technical projects of any degree of complexity, the project can benefit greatly from having that good liaison between the administrative and customer side of the project and the technical development side.  Having the BA in place to help translate those business requirements into functional requirements with and for the Tech Lead on the project is of tremendous value and helps keep that planning portion of the project under control in terms of time and dollars.  It can often definitely be money well spent on the Business Analyst position.  If it isn’t spent on that position on complex, technical projects, then it likely will be spent on a longer planning and design portion of the project.

3.     The Customer needs a technical interface to create complete, detailed requirements.  

Customers rarely come to the project table with detailed requirements and if they think that’s what they have then those requirements need to be questioned heavily. To get to usable, detailed, complete requirements is no small effort and the Business Analyst provides the best means of getting the project to the point of that detailed requirements definition.  On most complex tech projects, it’s going to be impossible for the Project Manager to be the sole facilitator of that process.

4.     A Business Analyst provides key assistance with user acceptance testing (UAT). 

User acceptance testing is critical to the project’s success.  So much so that the UAT signoff is almost like a signoff on the entire project.  But so many UATs can and do go poorly as many project clients lack the time, experience, and expertise to dutifully prepare for and conduct proper user acceptance testing.  While the delivery organization can’t do the testing for them, a good,  experienced BA – sometimes along with the Tech Lead’s and/or Project Manager’s help – can show them how to prepare properly and conduct UAT by assisting the customer with test cases and test scenarios.  This way both sides can be certain that the solution has been fully and properly tested prior to signoff and that the end solution is nearly certain of meeting the customer’s end user needs upon rollout.

5.     Business analysts provide critical oversight at project implementation time.  

Is the project complete?  Is it really ready for roll-out?  Probably, but have you gone through a project checklist to ensure that is the case?  Have you reviewed the project schedule to ensure all tasks are complete, that all sign-offs and approvals have been obtained along the way, and all documentation is there to prove it?  The Business Analyst – if you have one – has been involved in many of the key deliverables and heavily involved in requirements, functional design, reviews, user acceptance testing, and other testing as the solution moves toward implementation.  When the time does come for go-live, the Business Analyst can likely be the best interface with the project client – working closely with the Project Manager and the tech team to ensure the solution is rolled out smoothly to the customer and end users, that training needs have been identified and addressed and that the proper handoff to support has been achieved.

Summary / call for input

I’m a better Project Manager with a Business Analyst on board for the project.  Likewise, my projects are better equipped for success when I’m not splitting myself too thin as both the Project Manager and Business Analyst.  I realize that it is a luxury to accommodate both roles on the project as it can be a matter of budget, complexity and customer agreement.  Both roles need to be funded.  I still stand by the notion that every project is better off if you can have both roles filled separately, even if the Business Analyst or Project Manager role is very limited in terms of hours, dollars, and involvement.  Better to have a few hours here and there as needed as opposed to none.  So, if you can’t price both in full time, then price one in part time and strategically use those hours wisely where they are most needed – like early planning and design and then again around user acceptance testing where business analyst involvement can really help that often customer-challenged phase of the project go much more smoothly.

Readers – what are your thoughts?  How necessary do you see both roles as being on the projects in your organization?  How often does on or the other role cover both position on a project?  Please share and discuss.

Early Startup Go Project Manager or Business Analyst?

You’re an early startup bringing in new projects to work on. Clearly you need help. You need some structure. You need organization.

Your customers love your work but a couple of times it’s become obvious that the most senior techs need to be more hands on with every engagement and not involved as much in the day to day management of each project and the customer interfacing that always needs to happen. You’re doing it right by not trying to grow too fast – that can be disastrous. But now is the time to expand and add some structure to your project delivery processes.

Go Project Manager or Business Analyst?

So, do you add one or more Project Managers right now or do you look at adding a couple of experienced Business Analysts instead? It’s a tough decision because you know what you’re real need is, but you want to and need to grow slowly. The hope is that you can afford both. As a Project Manager, I believe you need both. I like to get my hands dirty on technical projects, but I certainly think that on technical, complex projects beside every great Project Manager is an equally great Business Analyst. The Business Analyst makes the Project Manager better at their job, helps the project to go more smoothly, certainly helps ensure that technical requirements are well documented, and helps ensure that smooth transition and translation of requirements to the technical development resources. Basically, the Business Analyst is the Project Manager’s and the tech lead’s new best friend and often the glue that holds the administrative side and the technical side of the projects together.

So where do I stand on Project Manager versus Business Analyst when you can only have just one? First, let’s determine that you can have only one.

Related Article: Project Manager and Business Analyst in Tandem for Success

Let’s review the scenario again. You’re a relatively early startup and going through some growing pains. You are taking on more projects and taking on projects that are likely increasingly challenging and complex in nature as your capabilities grow and your staff expertise grows. Now you’re faced with a decision. Up to now you’ve been having technical resources lead your projects, but you’re on the verge of landing (or have just signed up) some bigger clients and you are actually faced with the need to add structure to your project processes, and you need to do that fast. Which direction do you go? Do you grab two or three good Business Analysts and ask them to take on the PM and BA roles for now or do you acquire two or three experienced Project Managers and possibly another one or two senior technical leads and go from there?

Let’s face it, you’re growing well and acquiring clients so eventually you are going to need everything. If you have enough now to staff Project Managers OR Business Analysts, what do you go with first? My suggestion would be to write a cross-over job description, post it and see what interest you get. You could even post it as “Project Manager or Business Analyst.” Or post it twice – once under each title but with basically the same job description and experience requirements and make sure they cover some key aspects of both roles. The available and interested applicant pool may actually make the decision for you, but not likely. You’ll get Project Managers, Business Analysts, and independent consultants – many of which have plenty of experience in both types of roles. In fact, you may just – for now – create a hybrid role that is more of a “Project Analyst” role that may even include some additional technical hands-on work depending on who applies for the role.

My Ultimate “Right Now” Choice – Go Business Analyst

Eventually, if you’re showing the ongoing forward progress and success that this article is assuming, you’re going to need to significantly expand your project management infrastructure. Organizations like this are usually best served to have a formal project management office (PMO) in place led by a PMO director. Of course, that is not where we are in the scenario – yet – with this article. But you are growing, and the big question is what is the best area to focus on and use your money wisely on? And it is my belief that the first real expansion move is to add some business analyst talent to your technical staff as that’s the likely next real need on the growth curve. I’ve been added as a PM successfully to an organization that was in exactly this situation. It was the right move for them, and I don’t think an organization could go wrong either way as long as the growth is slow and well-planned out.

Call for Input

This is definitely a good problem to have – I think just about everyone will agree with that statement. You’re growing, that’s great. You need Project Managers AND Business Analysts, and that’s great, too. And you’re trying not to augment your staff all at once with everything you need because you know full well what can happen if you expand rapidly and lose a client or two through the learning curve and ramping up process, it happens, and it’s unfortunate and it can affect your client base, your reputation with customers and your reputation as a hiring organization…as well as make your current dedicated and experienced employees uneasy – and you absolutely cannot afford to lose a single one of them at this point. Backwards progress is not on the table.

What are your thoughts? You’re the CIO or CEO making tough choices. Which way would you go and why? Project managers and senior technical additions or Business aAnalysts and senior or possibly even – for now – junior technical additions? You know you’re going to eventually need all of the above, so there’s really no wrong move. But what serves you – and your current and short-term future project customers the best? That’s the tough question. Please share your thoughts (and experiences?) and discuss.

Make Sure Done Means Done

You’ve come to the end of a long technical project, and you’re rolling out the solution to the customer and their end users.  Perhaps it’s a handoff; perhaps it’s a training session or some sort of demo dog and pony show.  

But you’re looking for final signoff so that you can proceed with final billing and closure as you switch from delivery to support of the engagement.  The last thing you want to do is find out four months from now that you have an open invoice because you failed to finalize a particular project deliverable by not obtaining an approved signoff.  For the project manager and business analyst – who often leads the actual development of documents and preparation for things like user acceptance testing (UAT) standpoint – that can be a bit embarrassing.

Anything left unfinished can give the appearance that you are anything but in complete control of your project.  That’s bad because any items not complete may give the customer cause to be concerned about thoroughness in other areas of the project.  You want this client to be confident that you and your team have done your jobs.  You have tested and delivered the solution the client is expecting, and that everything will work when you wave good-bye and flip on the switch.  In short, you also want full final payment.  I know, I’ve been on one of those issue-filled projects when the client was concerned to call it done because so many issues had come up near the end that they were certain there would be more.  Gaining final acceptance and payment was excruciatingly painful.

Related Article: Getting the Project Client to Focus on Requirements

To ensure the project is done, here is my list of four key areas to cover and actions to take as the project is closing down.

1. Review all invoices for payment in full.  The Project Manager likely will need to lead this task – with the help of the Business Analyst.  Review all invoices with accounting and ensure that all that were sent to the project customer have been paid in full.  If any invoice is left unpaid, check with the customer to see if there was any reason for this.  Was there a problem with the deliverable?  Was it just an oversight?  I had this happen on one project and there were no issues. The project sponsor had just failed to pass an invoice along to his accounting department for payment, and once I contacted him, they promptly paid.  On very large projects, this is not all that uncommon to have happen.

2. Review the project schedule to ensure all deliverables show complete.  The Project Manager and Business Analyst should carefully review the project schedule to ensure that all tasks have been properly updated and show as completed in full.  Review any question marks with the resource or resources assigned to those tasks.  The key here is that you want to be sure you can hand over a revised project schedule to the project customer that accurately depicts all tasks as 100% complete and signed off.

3. Contact the client to see if they have any concerns about remaining outstanding issues.  The Project Manager and Business Analyst need to conduct a meeting with the client to discuss the project at a high level and find out if the client has any concerns over any outstanding issues or uncompleted work.  This meeting is not the same as a lessons learned session – the purpose of this meeting is just to ensure agreement on the completeness and verbal acceptance of the final solution.  While verbal acceptance is good and something you want as you’re working on this final check of project done-ness, never overlook that formal final signoff and acceptance by the customer.  It could end up being the most critical document on the entire project!

4. Review acceptance test documents.  One huge sign of final acceptance is final customer signoff and approval of user acceptance testing.  The customer handles test cases and test scenarios.  The Business Analyst and other tech staff on the project can help them, as needed.  But the Business Analyst can’t do it for them.  If the BA did, it could cause a conflict of interest because the delivery organization – as the developers of the solution – may have be biased when it comes testing.  The real testers needed are the future end users of the solution.  When their testing is complete we’ll know the project is ready to be accepted and signed off (as long as there isn’t a gap between the documented requirements (approved and signed off by the client) and what the end users need).  If there is a gap, then you’ll be drawing up a very large change order.  The project customer needed to have ensured that their end users were on board with acceptance of the documented requirements and project scope way back at the beginning of the engagement.  Any work on that now will be expensive.

Summary / call for input

There’s never a guarantee that you’ve covered everything.  I once closed out a year-long agreement with a client and then realized that I had agreed to a two-part billing on a deliverable to give them additional time to pay.  Instead, I completely forgot to bill part 2 and collect it – remembering it only when I was ready to invoice new work at the end of that first engagement.  The client knew they owed it. However, it was my sloppiness at handling the billing that caused delays.  While I did finally get the 2nd portion of the invoice paid, it took awhile because it was not a small amount.  At least, in that case, I hadn’t dropped the ball on a deliverable, just an invoice.

What about our readers?  Have you had any embarrassing rollouts where you realized – or the customer pointed out to you – that something had been skipped?  Possibly a deliverable was never produced, or a document was never revised following feedback and delivered in its final format?