Author: Brad Egeland

Dealing with the Jerks on the Project

Written by Brad Egeland on July 24, 2018. Posted in Articles. 1 Comment on Dealing with the Jerks on the Project

I hate to call anyone a jerk. There’s no getting around it… rude says one thing, but jerk sort of says it all while still keeping your language and integrity intact.

You deal with someone who has less consideration for mankind than you do every so often, I’m sure. Both in your personal life and in your professional life. It’s unfortunate, but it’s life. And how you deal with it – or them – says a lot about you and keeping your responses and actions/reactions controlled can mean the difference between success and failure.

I had a fun moment on date night with my wife last week. I dropped her off in front of her favorite women’s clothing store in Downtown Summerlin in Las Vegas and began my mission of searching for an impossible to find a parking spot to show off my awesome parallel parking skills. After losing out on four other spots that I noticed and tried not to run over texting shoppers to get to I finally located one and it was mine. Mine! Then the aggressive jerk behind me pulled as close to me as possible and waited trying to discourage me from backing into the spot. He didn’t know who he was dealing with. I waited, he waited. I put it in reverse and even backed up just enough so he noticed. He didn’t move. So I waited some more. He waited some more. Every vehicle behind him understood and left. Yet he stayed. I still had my reverse lights on. I even honked my horn a couple of times and politely waved him around. Still, he stayed. Finally, after about 5 minutes he got upset enough that he speed around me as fast as he could nearly clipping my vehicle in the process. Victorious, I took the parallel spot I had earned. Won actually. Yay for me.

Ok, in terms of project management I’m not talking about parking spots or road rage, and not really the team either, though that can be the case at times. It has been for me on my team a couple of times and with colleagues in the PM infrastructure a couple of times. I will get to those types of situations here as well. But it can be outsiders – maybe more like “extended relatives” in the PM world like stakeholders, senior management, customer team members, etc. Unfortunately, this probbly comes up more for business analysts than project managers considering the wide range of positions and individuals they must deal with and work with on a daily basis.

Now that I’ve established the population and genres that I’m about the attack… let’s do this. Here are some of the jerky situations I’ve found myself in, or colleagues have, or you may so I’m hoping to help here a bit… read on…

The figure head customer project manager.

Have you ever had a project customer who placed a “project manager” on their side and it seemed like his only job was to be your watch dog? I have – really just on one major technical implementation. He never really contributed anything to the project – he just mimicked what I did, relayed what I said and emailed me a lot to check progress. The progress information was readily available to him in the weekly status I was producing and sending, the project schedule updates I was providing and the daily email updates I was sending out to all key stakeholders. So at the end of the day, he cost the project a lot on the customer’s side of the equation while apparently adding no value. He was often rude and sarcastic even though the project was going well but I knew it was in my best interest to move forward, not complain, and continue to provide him and the rest of the stakeholders with the same high quality and – often daily – updated status information I was already providing. The key is to stay in control, and control how you respond and interact.

The PM colleague who has advice for everyone – a.k.a, a better way of doing things.

Have you ever had one of those colleagues who seems to know a better way of doing things and needs to interject that into nearly every conversation you have with them? I did once. It’s almost amusing but it is certainly annoying. Especially when you really don’t need the advice but it is somehow validating to them. The best response, stay heads down working and respond kindly. I’m never big on creating workplace drama – I like to avoid the drama as much as possible which is probably why I work so well remotely and managing virtual teams. I like the camaraderie with team and colleagues, but I can do that through email and Skype and video conferences just as well if it cuts out the 10-20% time lost to individuals who are focused on the negatives or other things that are not productive to my work, my team and my projects. I’m certainly not anti-people, but I am certainly anti- gossip, busy work, complaining and time-wasting. Avoid these people when possible, and politely keep working while they show up to vent or interject to you in your office. Stay in control of yourself and your actions – that is always the best route to take.

The customer who wants everything for free.

I actually had this one happen just two weeks ago… again. It happens periodically on projects and in consulting engagements. Everyone wants free publicity and freebies or free project add-on work without thoughts that maybe your company will incur expenses getting this done for them or that maybe you even have kids to feed – like in my case. The client contacted me outright, not the other way around. I quickly drew up a proposal for him in the middle of the night because this was an international potential client and I wanted to respond quickly since he was likely near the end of his company’s work day and seemed anxious to move forward. He quickly replied that he wanted the free version. I wasn’t sure what he meant by “free version,” but I replied, “great, you can have this work free with these other ‘x’ services.” His response? “No, I just want the free version.” I explained that either way it takes time and effort on my part. He still wanted the free version so I had to cut him loose even though I was still offering him a great value for what he really wanted. But I could not give it away. Sometimes you just have to walk away when they don’t get it. Your time is worth more and you lose money giving too much time to those potential project clients who just don’t understand the value. They probably never will. Cut your losses and walk away… unfortunately, that’s what I had to do.

Summary / call for input

Again, I consider myself a fairly nice guy and I’m very flexible and easy to work with unless you are A) Endangering my family in any way, B)Trying to mess with my project, or C) Trying to take my parking spot that is rightly mine (apparently after this current experience). Just be fair and others will be fair to you… usually. Sort of the golden rule, you know?

Readers, what is your take on this list? Do you agree? What jerks have you had to deal with and how did you handle the situation? Please share and discuss.

5 More Tough Questions Business Analysts Face on Tech Projects

Written by Brad Egeland on June 7, 2018. Posted in Articles. 32 Comments on 5 More Tough Questions Business Analysts Face on Tech Projects

I cover tough questions that business analysts may face on an earlier article here entitled “Top 5 Top 5 Toughest Questions Faced By Business Analysts On Tech Projects.”

It seems to have been fairly popular with our readers here so I wanted to address more potential questions that can arise for business analysts on the projects they are helping to lead. Customers have lots of needs, and the business analyst is likely their most frequent communication point on a daily basis – especially on the more complex technical projects.

This can probably be a never-ending list, and I will probably address more in a couple of months, but for now here are my next five tough questions for business analysts…

Can this be hacked – is my data safe with you?

Everything can be hacked – and in this age that can go for just about any data on any project you might be managing or working on at any given time. I know that sounds like a mouthful and probably sounds like a bad trailer for a low budget horror film, but it’s true. If they aren’t going after you, then it’s because they don’t care about the data you are managing or that your customer has in their data solution you are working on. Yet. But it can happen. 25% of my past and current customers have been hacked in the past year and affected in some way… though thankfully not due to my oversight and none have been very damaging to them… so far. But that can change overnight, and it is likely they will ask you on every project going forward that has some data element. Be aware, always manage hacking as if it is a real risk. You can’t likely ever fully prevent it, but you can take precautions, you can make your organization’s security team or CSO part of your project team that checks in from time to time and you can consider mitigating actions to take in case of a hack. Do it.

Am I going to get slammed with change orders?

Nearly every client worries about getting slammed with change orders even if they don’t always mention it. You need to convey from the outset what your change management process and methodology is, and help them to understand the guidelines that will result in change orders being presented to them. And most of all, you must do a very good job of requirements definition and documentation and scope management. Yes, overall that is a project manager’s responsibility. But who is managing the ongoing development work on a daily basis in the real world – beside the tech lead? That’s the business analyst. Manage it well and keep the customer up to date on any potential needs that could result in change orders. They never like surprises of this kind.

Do you have the right skill set on the project team to pull this off?

The project customer is paying the bills for the project – so they need to know that those expensive resources have the right skills to pull this off. Especially if you are dealing with new cutting edge technology. The best you can do is comfort them by providing background information on the team and keeping the customer up to date on a daily basis on the project tasks and progress – especially the more difficult project tasks. Don’t let them get that unsettling feeling that their solution is in the hands of questionable talent… even if at times the team may be learning as they are going. You can know that, the customer should never hear that.

Why isn’t my project more important to your organization?

Your customer is going to want their project to be at the top of your organization’s priority list. If they feel like – in any way – their project is less important than any other project in the organization or on your project plate, that can cause them great anxiety. Never let them think that you are being pulled away to other projects you are working on or that any of the team members are overloaded on any of the other projects they may be involved in. You can know that and juggle whatever you need to juggle to make the work happen and help the tasks get completed. But that needs to be behind the scenes and not apparent to the project customer at all times.

How can I effectively test this solution?

Project customers and testing on tech projects. It’s a difficult mix at times. In my early project management days I was tossed into the fire right out of my role as an application developer to oversee most of a $50 million government tech program with very sensitive data and very necessarily deadly accurate output as it was always financial in nature. Part of that management was overseeing the testing portion of the program and system on an annual rollout basis. Preparation was long and thorough, requirements and acceptance standards were ridged, and the incoming government testing team was needing and opinionated. A difficult combo. I learned early on that not all testers are created equal. You can not do the testing for them – that would be unethical and a definite conflict of interest. But it is everyone’s goal to get through it as painlessly as possible so help them. And when they ask this questions show them how to write test cases and test scenarios, be available 24/7 to answer questions and hold hands and never be afraid to steer them back on track. They know you’re the expert. And most customer end users don’t care about the details, they care about the correct outcomes.

Summary / call for input and feedback

Again, the bottom line is we want to turn over successful projects. Our project customers are nervous and inquisitive if they are involved. Be ready with the right answers to keep them confident and keep them from micro managing.

Readers – especially business analysts – how do you feel about this list? Does this match your experiences? What would you add at this point? Please share and discuss.

5 Steps to High Customer Approval Ratings

Written by Brad Egeland on May 16, 2018. Posted in Articles. 1 Comment on 5 Steps to High Customer Approval Ratings

We all want success on our projects. It isn’t easy to obtain, though. Surveys and studies put the average project success rate at anywhere from about 44% to about 57%… those aren’t great numbers now are they?

And by success, I mean real success. Successful projects are usually based on one or all of three factors depending on who is doing the judging. These are on time delivery, on budget delivery and customer satisfaction. Which one is the biggest to you and your organization? That may depend on who is doing the judging.

I can guarantee you that the CFO is most concerned about the financial bottom line. The CEO is probably concerned about all three… but he’s probably most concerned with the customer satisfaction level as that’s where customer referrals, testimonials and returning engagements come from. And the rest of the stakeholders are likely somewhere in between.

I have five steps to consider on the road to the highest customer approval rating possible… as you read please think about your own list and feel free to share…

Hands on customer engagement.

Yes, you may not think so or want to do it, but your customer wants and needs your hand holding on many project engagements. The more they know that the project is going well, that their money is being spent wisely and timely, and that forward progress is always being made, the better. And it’s all about their customer satisfaction. Hands on means lots of communication – which is Job One for the project manager, business analyst and team. Don’t skip status reports, don’t cancel meetings, don’t slide deliverables whenever possible. Even if they aren’t always examining every detail and listening to every word, hearing you and seeing your reports and emails tells them a lot and sometimes enough about what’s going on and how “on it” you are. That gives them a warm, confident feeling. The less they hear from you the less they think you are doing. Don’t give them the opportunity to wonder and imagine that things aren’t going well. Show them that they are going well.

Key aspects of the team-customer communication process.

Be careful when communicating with the client. I believe in 100% transparency for both the good and the bad information on the project. But the bad must be analyzed before conveyed. Do you like it when someone comes to you with only bad information or a major issue or do you prefer they come to you with bad information and one or more proposed courses of action. Now if it’s your 4 year old son which it often is for me, his choice of mitigation may not be the best one to act upon, but when your project team comes to you or you go to the project customer, it is very conceivable – and expected – that you’ve dutifully thought it out and have 2-3 actions plans to discuss and choose from. Trust me, your customer confidence and overall reaction to the bad news will be much much higher if you present potential and workable solutions with the bad news.

Project meeting planning and management.

Well planned out project meetings can end with higher productivity in the meetings also resulting in higher customer confidence and approval ratings. The well planned out meeting isn’t that hard to pull off. Stick to what I like to call my key ingredients to the perfect project meeting and your customer and team – and all stakeholders – confidence, satisfaction and participation levels will be the highest possible…

Put out a clear agenda in advance every time. Always provide and agenda and general status in advance to all expected attendees. This way everyone will know what is expected in advance and will come prepared to discuss – no excuses.
Focus on a meaningful purpose. Focus on what is necessary and what you want to accomplish. Being too broad or too general will result in less productivity and more followup meetings.
Don’t hold meetings just to hold meetings. Be specific and make your meetings important. But don’t cancel easily either – cancelling regular revolving meetings can cause individual attendees to lessen the importance of your meetings in their own heads and it will become easier and easier to skip your meetings. Keep the meetings even if they are shorter in length than planned – you never know when a critical piece of info may fall through the cracks if you cancel.
Start on time and end on time. Be punctual and don’t get in the habit of bringing latecomers and no-shows up to date. That’s their job – and if you do so they will always come late or skip.
Followup with notes. The goal of any meeting is communication. Follow up with notes afterwards and ask for feedback within 24 hours. You want everyone on the same page as you move forward.

Resolving issues and errors in delivery.

Taking care of issue and error resolution in a timely fashion will always help with customer satisfaction. Too many times – especially with tech projects – we hand the end solution off with a few outstanding issues and plan to regroup later or leave for the customer to deal with.

Of course we do this only with the customer’s blessing, but wouldn’t it be better if we could hand off quality, error free solutions rather than something that is 95% of the way there? Strive for perfection always and expect the best – as the customer should expect. Put yourself in their shows… if you’re buying a new car are you happy driving it off the lot with a couple of scratches that you agree to bring back in the next month to have fixed? Not likely – you’ll do it but it doesn’t mean you’ll ever feel good about shopping there again for a new car. It’s a lot of money to spend on something that isn’t perfect.

Handling final review and sign off of the project with the customer.

A quality end project handoff is probably one of the single biggest things you can do to ensure high customer confidence and approval ratings. How do you do that? Plan for and schedule and actually conduct a lessons learned session post implementation. That chance to regroup and review the project tells the customer you care and will lead to a much higher likelihood of return business no matter how the project went. You also do it by planning with support and your own team to support client needs post implementation for a specific period of time… one month, three months, whatever. It says I care and I’m responsible for the work I’m handing off.

Summary / call for input

These are just five steps out of many to help your customer gain and keep confidence in how the project is going and therefore remain more confident throughout that the end result is going to be successful.

Readers – what is your take? Do you agree with this list? What would you change about it? Please share and discuss.

4 Tactics Business Analysts Can Employ to Keep the Project on Track

Written by Brad Egeland on April 18, 2018. Posted in Articles.

Who or what makes the big difference as to success or failure on a tech project? Is it the project manager?

Is it the business analyst? The tech lead? The customer? The budget? The timeline? Luck? The skill set of the project team? 3rd party vendors? Unknowns? Issues? Risks? Requirements? Good or bad communication?

If I had to pick just one, I’d probably go with that last one since I think good communication is an absolute for any project success. But in reality, any and all of these can and do contribute to project success or failure. That said, I feel strongly that a good business analyst is tantamount to project success as well. And here I am going to cover four tactics that a good, experienced and proactive business analyst can employ to help keep a potentially troubled project on track for the remainder of the engagement. Agree? Disagree? Or agree to disagree? Tell me at the end the who, what and why about how you feel about what I’ve presented here and let’s see if we can figure this all out together so we can have some new strategies to deal with the pain that is the complex project problems experiencing issues and all have a better chance at a project win. It’s all about sharing ideas and winning on projects, right?…

Take over the development team.

The business analyst is usually the liaison between the project manager and the project tech team on development related projects. At least, for me, that’s how I like to set my teams up as I already have enough overall project management responsibilities to deal with daily. They are also serving the same role in the project team ==> customer sponsor/team relationship. So, to go one extra step, the business analyst can and should fully take over the technical project team from a day to day task management aspect on a complex development project – especially if there are any issues threatening to push the project off its rails. I’m not saying that proper oversight should be taken from the project manager – but there is enough organizational responsibilities and communication activities need from the project manager on a complex technical project. It makes sense to hand the project tech team over to the business analyst.

Have a separate one-off meeting with the project customer once a week.

As part of the customer service aspect of the business analyst role, this individual can and should have a separate status call with the project client – less formal than the one led by the project manager each week that usually involves most or all of the major stakeholders in the project. The business analyst meeting should be just a one on one with the project sponsor or possibly also include the delivery tech lead and the client side top end user or subject matter expert (SME). In the most complex project situations, the project can even be adjusted to place that business analyst onsite full-time with the project client if that helps and if there is money available (budget or change order or otherwise) to make that happen.

Back to the meeting concept… this meeting should involve running through any key issues that are happening at the moment, a look at what’s happening in solution development and what’s about to start happening, plus any ongoing change order activity. This meeting will serve some clients’ needs for more of an informal “let’s get this done” approach.

Take over issues and risks discussions at each weekly status meeting.

While the business analyst is conducting their own more casual project discussion with the customer, the weekly formal project status call would still be led by the project manager, of course. However, since the business analyst usually is the project team member most closely on top of the status of issues and issue resolution on the project, he could be and – therefore, should be – the individual leading that part of the weekly discussion with the team and the customer for the formal project status call.

Be the go-to person for scope management.

Another key area that the business analyst should take over as the point person on is scope management. They are more likely to be working with the team and customer on day to day development activities as well as keeping any requirements documentation up to date as they are the ones working through any project change requests face to face with the development team and the project client. The project manager is still the overall project scope person and needs to know where things stand every step of the way in terms of project scope, change requests and change orders, but the business analyst will be the one creating change orders, tracking down tech lead estimates for the work required by the change order and then discussing the change order with the project client for sign off and work proceeding.

Summary/call for input

I’m not in favor of the project manager passing all important batons to the business analyst. But I do believe one of the key roles for the business analyst is serving as the liaison for all to the development team on a technical project. Given, then, that the business analyst is key contact with the dev team, then it also makes sense for them to lead the development team, lead discussions with the team on what they are working on each week, and lead discussions with the project client – and all key project stakeholders – concerning the status of what the development team is working on each week and the progress being made on those tasks.

Readers – what’s your take on this list? Do you think a business analyst taking the lead on some of these responsibilities will help or hurt? Business analysts specifically – what do you think about this list? Can you give us some examples of when you’ve had to take the controls and help keep the project on track and what areas or actions helped the most or made the most difference? And were you too overloaded? Please share and discuss.

Two Business Analysts are not Necessarily Better than One

Written by Brad Egeland on April 3, 2018. Posted in Articles.

More is better right? Especially if you can afford the luxury of having more and paying for more.

Two pizzas are always better than one. More cake – or any dessert for that matter. More lobster, more steak, more money, more cars, more speed, more knowledge…

In many cases – at least on the surface and in general – more is better. Unless your a crazy cat lady. One more cat might be the one that gets you locked up or evicted. But I don’t like cats much anyway.

What about business analysts on a project. Two business analysts on the same project just means more work gets done faster, right? Business analysts out there… is this true? Do you agree? Have you ever been on a project where you were one of two or more business analysts on the same project? Save your thoughts and tell me about it at the end… would really like to hear your experience and especially why there was more than one of you on the same project.

I did have two business analysts on two projects and it wasn’t all that I expected it to be. It actually caused more problems than it solved or avoided so by choice alone I would never do it again unless it was forced on me. And it essentially was those two times. Let’s discuss reasons why this could be bad – and the list does include things that happened to me and my projects when I had multiple business analysts working together or whatever you might call it (against each other ? ) as well as things I have witnessed on other projects….

Customer concerns over who’s really in charge.

Ok, the project manager is in charge. But on many projects, the business analyst is often a primary point of contact for the point person the customer side – especially once the real project starts post kickoff. Management and oversight and primary communication and status comes from the project manager, but in the trenches type information and communication may likely come from the business analyst. With two business analysts, the customer could be concerned or confused over who the main business analyst contact is. I didn’t really experience this, because on both of my situations it was obvious – and discussed early on – which one was senior and which one was junior… which leads to my next potential problem and I did experience this one…

One senior, one junior.

On day one of the project, our PMO director – who was present for the project kickoff session – explained that one business analyst was senior and one was junior and learning from the other. Ugh. This was a horrible thing to admit upfront. The junior business analyst was fully competent and also the one who was always 100% available to the project. The other – more senior business analyst – was stretched too thin across three busy projects at the time including mine. But that doesn’t matter to the client… what they heard was one was good and one was just learning… or that’s what they took from it. From that point on they questioned everything the junior business analyst said or did and insisted the other, more senior business analyst, also review it. What they weren’t told was that he wasn’t that available to do it. Thank you my dear PMO director. He caused me several headaches, and this was one of the biggest ones.

Customer concerned over cost.

Likewise, cost becomes a concern and this is one that I experienced. We stayed on budget because I knew upfront that I had two business analysts and strategically worked the cost and effort into the timeline. But the customer was constantly concerned about costs on the project for one of the two engagements. Thankfully, I was able to show them often and in detail that we were doing fine so by halfway through the project that wasn’t such a problem, but it did take several months to get to that customer comfort level with my management of the BA costs.

Fails on certain or overlapping tasks. This can be an issue as well if tasks aren’t well delegated and the assignment line is blurred. It didn’t happen to me but I watched tasks get dropped on other project managers’ projects in an organization that somewhat frequently assigned two business analysts to the same project. Task assignment and management is key here between the business analysts – so communication between the two BA’s must remain high to keep tasks on track and well covered.

One business analyst gets pulled from the project.

Love this one. Management, for some reason, assigns you two business analysts – mostly for one to learn from the other in most situations – and then because you have an “extra” business analyst who has been built into the schedule, they take them for a new project. And which one they take depends on the new project. If it’s more important or a higher visibility project than yours, they take the senior business analyst. And likewise, if it’s a smaller project and they feel this more junior business analyst is up for it, then they will take him. Either way, your project may be heavily affected if you had enough tasks to go around. Suddenly, you’re left with a big gap in your schedule – either one business analyst who is now way overloaded on tasks or many unassigned tasks that have to be spread across the entire team (or maybe you need another business analyst). The best you can do – especially if you have some tenure or pull in the organization – is fight to get a similar resource added because if you have to slide project deliverables out for this reason your customer is not going to be happy about it. We all know that the likely scenario is that you’re going to have to make do with what you have and both cut corners and move out some deadlines – time to negotiate a little with the client to keep them from being too upset. Think of some reasons to give them to make them maintain confidence and satisfaction levels… look for some pluses to push on them… it won’t be easy so be creative.

Summary / call for input

Two of a good thing is not always a better thing or even a good thing. So that’s my list – what’s yours? Have you ever had or been more than one business analyst on the same project? What happened? Conflicts over tasks? One reviews everything the other did? Did you team up on the tasks and project as a whole or attack entirely separate areas of the project? If you’ve done both, then which was was more effective. Please share and discus.