Skip to main content

Author: Brad Egeland

Getting the Project Client to Focus on Requirements

Written by Brad Egeland on . Posted in Articles. 1 Comment on Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.

Summary

There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers?  What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements?  Please share your thoughts and expertise (and failures if you don’t mind).

5 Key Soft Skills for IT Business Analysts

Written by Brad Egeland on . Posted in Articles. 1 Comment on 5 Key Soft Skills for IT Business Analysts

Business analysts play a critical role in the project management life cycle. Especially when the projects being managed are technical in nature. Success or failure of the project manager and team sometimes relies on the skills this individual brings to the table and the way they can interact both with the technical project team and the project client.

What soft skills does a technical business analyst need to help ensure the success of the project engagement? It depends, of course, on several factors. The needs and experience levels of the project manager and technical team members. The needs of other key project stakeholders. And of course, the needs and – most likely – the technical skill level, understanding and competence of the project customer with regards to the solution that is to be delivered. Often the business analyst is that final interpretation and documentation point of those critical project requirements. The business analyst should be at the middle of the definition of those key requirements.

Let’s examine what I consider to be the top 5 key soft skills of IT business analysts when working on technical project solutions with the project team and customer.

Negotiation. The art of negotiation. It’s not an easy one and it’s not for everyone. It takes confidence, connections, proactive thinking, and a solid understanding of the other party’s needs. That’s where the technical business analyst needs to thrive. As they are continually working through the technical side of the project with the project client – acting as a constant interface to the client and as a liaison to and interpreter for the tech lead and development team as well as a administrative support role for the project manager (yes, that is three hats on most projects), they have the best understanding of client needs vs. delivery team capabilities. That’s where negotiation comes in. They need to be able to see where new business might be negotiated with the project client as well as where project changes may need to be negotiated to combat scheduling conflicts.

Meeting management. As with any professional position, the business analyst will be well served to be a good meeting manager. Besides participating on regular project status meetings led by the project manager, the BA will be conducting many project meetings throughout the project engagement. These include meetings to discuss and define design and planning issues as well as functional design and project requirements with the client. They will also be conducting many team meetings with the developers as they transfer and translate ongoing customer needs and requests. Efficient and effective project meeting management will keep attendees coming and keep meetings productive.

Conflict resolution. Hopefully this skill isn’t needed often, but that always depends on the team and the project – and possibly the customer. The complexity of work can bring conflicts on the team. The business analyst who can work cohesively with the project team can help wade through the conflicts and help project team members realize they are working on a common project goal and keep them focused on that.

Listening skills. Listening skills are critical for the BA. Both in terms of dealing with the wants, needs and requests of the project client and listening to the concerns and needs of the technical project team members. Proper understanding of client processes and needs is critical to proper documentation and understanding of those always important detailed project requirements – and the BA’s listening skills are at the heart of that understanding. Requirements are the lifeblood of the project – poorly documented or understood project requirements have doomed many a project. Success is hard enough as it is – listening skills are critical for the BA to avoid this potential pitfall.

Communication. Finally, communication. I realize that listening is part of communication, but here I’m talking about the other side. The business analyst needs to be a master at interpreting what they hear and accurately relaying it to those with whom they are connecting. The BA is often a go-between on many aspects of the project as already discussed. If any of that critical information falls between the cracks, it can lead to nightmares, missed deadlines, re-work, and budgetary issues. And, likely, ultimately project failure and delivery of a solution that doesn’t work for the client’s end users.

One other key communication point is how the business analyst communicates with the project customer. Communication throughout the engagement can determine the customer’s ongoing confidence in and satisfaction with the delivery team’s work and ability to deliver on the project. A BA who is only working closely with the project team and project manager may cause concern with the project client. A technical BA who is “on it” and shows great understanding of the client’s needs, concerns, and requirements keeps the project customer’s confidence high, their satisfaction at a desirable level, and their readiness to continue to do business on other work with the delivery organization likely. In reality they are an extremely critical interactive position with the project customer and the area of communication is of utmost importance. I always say it is Job #1 for the project manager. Likewise, I believe the same of the business analyst. It is an absolutely must-have soft skill for a BA on projects of any complexity.

Summary / call for feedback

I’m not saying a project can’t survive without a skilled business analyst. I am saying that I would not want to be leading a project of significant size and complexity without an experienced technically skilled and knowledgeable business analyst working alongside me helping me lead the project and engage the client.

How about our readers? What are your thoughts on the soft skills of the business analyst? Does this list work for you? What other items would you add to it that you see as key tools the business analyst needs to bring to the technical projects they are working on with the project team? What role are business analysts expected to play on your project management teams? How much interaction with the project customer and how much technical acumen is expected of this position?

5 Reasons Business Analysts are Indispensable

Written by Brad Egeland on . Posted in Articles.

In my opinion, a project without a business analyst is doomed to fail. I may be exaggerating a bit and probably even underrating my ability to fill both roles, but I was a bit spoiled in my last W2 project manager position. I had very skilled business analysts assigned to every project I was leading. I helped them with requirements and functional design documents, but they did the real work. They made it all make sense to the developers. The tech lead knew who to go to with questions in terms of requirements and scope. I could do it – but the BA already had the walking around knowledge so he was the go-to person on design issues for the tech lead if he was around.

So, in my opinion I consider business analysts to be indispensable if you want your IT project to go smoothly and be successful – which hopefully is your goal every time. What I’d like to outline now are my 5 reasons why I consider the BA to be indispensable on technical projects. I’ve played my hand on one above, but I’ll reiterate that one below.

The BA communicates with the project client. The project client has project needs to express, some technical, some not so technical. And some clients are very non-technical. But when the project client has a complex technical need it’s nice to have a skilled, technically competent business analyst on the delivery side to discuss the need, identify the REAL need and work through requirements with me on the project with the project client. Having this resource on the project greatly increases the odds that we will hit the mark on meeting the real client project need and the real client end user need at solution deployment time.

The BA is the technical liaison with the SMEs. The customer subject matter experts (SMEs) and end users can really benefit from having a skilled technical business analyst on the delivery project team. BAs can ensure that requirements are clear, concise and detailed. As I said, this can and usually does greatly increase the chance that the project really hits the mark in terms of meeting the right client need and the real customer requirements for the project. Plus, if there is a choice of technical solutions, the skilled BA helps ensure that the right one is picked. One more thing – the assistance that a skilled BA can bring to the project client at user acceptance testing (UAT) time is sometimes priceless given the fact that many an IT project customer is often ill-equipped to do a really good job testing the solution without it.

The BA connects with the technical lead. Having a skilled business analyst with technical knowledge on the team can provide that necessary link to the project team technical lead as you try to move from requirements and functional design document to the technical design and technical design document from which the solution is created. The knowledge the BA carries with them helps ensure key requirements get interpreted accurately and that the proper amount of time, planning and attention is given. The project manager is busy with other tasks and the BA can assist at this point, it really helps the PM perform well in the lead role they are performing.

The BA makes the project manager look good. A very competent business analyst makes the project manager look good. A busy project manager often has enough to do managing the project team and resources, creating project status reports, running the weekly project meetings, managing issues, risks and financials and – of course – managing the project schedule. Having a technically skilled business analyst on the engagement ensuring that the delivery goes smoothly and the communication with the technical team is handled properly can really make the project manager’s life much easier. And that helps make the project manager look good.

The BA runs interference on technical issues. I realize that technical issues rarely come up on technical projects (yeah… right), but when they do, having a skilled business analyst to assign those issues to and then let them research and find the solution can really help a project stay on track. The technical staff on the team will still be responsible for the coding and some of the testing of these issues as fixes are created, but the business analyst will be the individual overseeing the issue from beginning to end ensuring that it’s handled properly and properly resolved.

There’s one more thing I left out – the project status calls with the customer. As the project lead, the project manager is leading the formal weekly status call with the client. But when technical issues are discussed and technical questions come up it’s not always possible to have the tech lead on the call. Having the business analyst available to go into the proper technical detail on the solution but put it in terms that the project customer can understand with can go miles in ensuring that the project customer is satisfied. BAs can help the client feel comfortable with the competency of the entire project team in running down issues, managing and performing on the project and delivering and overall successful end solution to the sponsor and customer end users.

Summary

Don’t get me wrong. I like to play hands-on technical project manager from time-to-time and when it makes sense. I stay up on technology and I attend technical conferences like Interop, Black Hat, Agile, Better Software Development, DevOps, and CES International to name a few. But as the project manager – usually running multiple projects at one time and with PM administrative tasks to take care of – I am usually too limited in availability to get too involved in the hands-on technical solution and tasks. That’s why a good business analyst is so essential and really makes the project go around.

How do other project managers and business analysts feel about this? Do you generally get the entire load dumped on you or do you have skilled business analysts you can rely on to be that technical liaison and knowledge bearer on the project? What other things do skilled BAs bring to the table on technical projects?

Don’t forget to leave your comments below.