Author: Brad Egeland

The Disruptive Business Analyst

Written by Brad Egeland on July 24, 2019. Posted in Articles. 1 Comment on The Disruptive Business Analyst

Disrupt. By definition disrupt means “to prevent something, especially a system, process, or event, from continuing as usual or as expected.

To throw into confusion, throw into disorder, throw into disarray, cause confusion/turmoil in, play havoc with.”

From a technology perspective, it refers to “any enhanced or completely new technology that replaces and disrupts an existing technology, rendering it obsolete. It is designed to succeed similar technology that is already in use. Disruptive technology applies to hardware, software, networks and combined technologies.”

So, what about the disruptive business analyst? I work mostly with tech projects so for me the disruptive business analyst is working with what we used to call bleeding edge technology on new projects for anxiously awaiting project clients leading tech teams on exciting and sometimes dangerous new project adventures. End users and subject matter experts are awaiting a nearly ready solution during user acceptance testing (UAT) and at implementation rollout to the end user community with this creative solution. Hopefully the tech team… and the business analyst… along with the project manager have provided a workable solution that meets their requirements dead on. This can be difficult, of course, anytime you’re moving to a new technology that you’ve not worked with before, the project team hasn’t worked with before, the client has never likely seen or used it before, and that may not have been implemented in the client’s type of industry before. You’re on the edge… you’re going where no one has gone before (well, with that customer in that industry anyway…).

Stay abreast of new technologies

Since the business analyst is usually at least the liaison between the tech team and the project manager on a technical project – and is sometimes even the co-lead or sole lead of the project – then it is obviously critical that he remain relevant and current of ongoing tech trends and new technology. Through regular training, reading and research, this is easy to do and in terms of products, technology and security, conferences and the exhibit rooms at these conferences are a great way to get first hand face to face knowledge and deep dive information from the individuals creating and introducing this technology. Conferences like CES (Consumer Electronics Show), Interop and Black Hat will have briefings, demonstrations and training available for attendees and they can be fascinating ways to enhance your knowledge level.

Ensure the right team assembled for the tech implementation

A new technology is being used on our high-tech solution for the project client. Is our project team up for the challenge? Is the learning curve reasonable or do we need part time or full-time consulting or new resources on the project? That initial assessment must be made or at least assisted by the business analyst. And this determination needs to be made – and not lightly – as close to the kickoff of a new project as possible so as not to result in a timeframe extension, budget overrun and big, long learning curve for newly on boarded project resources.

Oversee customer training and education on the tech solution and the technology used

The project manager works closely with the customer throughout the engagement. There is no question about that. But on many tech projects the business analyst works even closer and for extended periods of time. On one of my projects, the customer wanted a change order to have the business analyst work full time onsite for the remainder of the project resulting in a $100k+ change order with a high profit margin added to the project. I was happy to oblige, of course. Especially in cases like this one, the business analyst is going to have the best feel for the customer’s ability to understand and eventually take over a new high-tech solution. Should education and training take place? Often the answer is yes. Yet another change order revenue opportunity! Win-win. This is an area where the business analyst will usually need to play point on – be aware.

Ensure Cybersecurity measures are taken

While hackers know that organizations using legacy technology are the easiest target, most get more challenge and enjoyment from cracking new technology. If you are embarking on new tech adventures on your project, know that you may be a target, especially if you are handling any sensitive data with this new tech angle. So, know that if you’re utilizing bleeding edge technology, you are on the hackers’ radar – you are a likely target will need to take proper measures. It’s best to address this possibility early in the planning phases while assessing risks and the skill set needed for your project team.

Summary / call for input

Are you a disruptive business analyst? Most business analysts working with startups and large corporations entering new areas of delivery are going to be utilizing new and cutting-edge technology. The key is to be fully engaged, ensure the client understands – at least to some degree – the new technology and that you have the right talent designing and implementing the project solution. Oh, and that the end user community knows what they are getting. It never hurts to make sure that your project manager is on board with the same technical understanding. Project management is sometimes project management across all complexities and industries… but I’ve always felt that a technical background is critical to the tech project manager’s success in managing tech projects. Sounds logical – and it is logical. I’ve seen it with my own eyes. I’ve got the tech background myself, but I’ve seen many colleagues fail miserably on technical projects because of a lack of tech background and understanding.

Readers – what’s your take on this list and these areas of emphasis? What would you add to it or change about? Do you agree with it? Tell us about a project you played a key role on using new technology and how you managed issues and risks – if there were any – in the implementation. Was it smooth? A success? A failure? Let’s share and discuss.

Business Analyst = Cybersecurity Expert

Written by Brad Egeland on June 27, 2019. Posted in Articles.

Ok, this may be a stretch to say “cybersecurity expert”, but I got your attention, didn’t I?

To me – and on all the “real world” tech projects I’ve managed – the business analyst has played the role of part-time tech and full-time tech liaison with the technical team on the project. They run the requirements definition portion of the project, they document – with project manager assistance – the functional requirements for the project and help extract the project client’s current business processes that are or will be affected by the project as well as helping to analyze and define what the new processes need to look like as we build the solution that will satisfy the business needs of the project client.

Easy process? No. Lots of work involved? Yes. Lots of documentation involved as well and much of it will become the basis for the full, detailed requirements document as well as what the ultimate solution is tested against as we run through user acceptance testing (UAT) with the project client. Defining all of this is critical to selecting the right technology, fully and correctly defining what the real requirements are, fully understanding what the “as-is” and “to-be” business and technical processes are or planned to be and fully preparing for the rest of the project.

Now, that said, the project manager has his role. The tech lead and team have their roles. Often, everything else might fall to the business analyst. And as we manage projects in ever increasing dangerous waters filled with hackers and data breaches, the business analyst may be taking on a new role in the smaller and/or less prepared project execution organizations. That is the role of the cybersecurity “expert.”

I’ve often said two things: data security and hacking are such a growing concern that no project should be consider “safe.” Hackers are always one step ahead of us and if you were on their radar you would have already been affected. But you may get lucky for a while. Sooner or later you will be affected to some small or potentially large degree. You can’t necessarily completely avoid or mitigate the hacker / data breach risk. But you can take measures. Does every project need some involvement from security as a part of the project team – if only as a sit-in during risk identification? I think so. Will all organizations eventually have a team of cybersecurity experts? Probably. But for now, that cybersecurity team or presence may just be one untrained or “in training” individual who has a strong interest in cybersecurity (or is forced to have that interest). And who is that likely candidate? The business analyst. In fact, the smart organization would be bringing in cybersecurity trainers right now to start getting the ground work laid for a solid team of security individuals tasked with keeping organization and customer data and systems safe from harm. The larger organizations should be putting a CSO (chief security officer) in place to guide the security infrastructure down the right path and career growths for those hired to be part of that infrastructure.

So, does the business analyst really = cybersecurity expert? In some cases, yes. And in the case where there is no real security awareness, representation or position on the project and in the organization the answer – in my opinion – is a definite yes. Get those BA’s in the organization as a whole at least educated on cybersecurity at a high level so they can begin to integrate cybersecurity awareness on the projects, the project teams and with the company’s senior management. It will give your project clients a better comfort level of satisfaction and confidence and hopefully provide some useful mitigation planning. There are some cybersecurity 101-type documents, videos, webinars and classes out there – often for free. Yes, that is all better than nothing. It’s what I’m immersing myself in – you learn something new and helpful with every watch or read. And I’ve attended many Las Vegas versions of the Black Hat digital security conferences over the years. They aren’t cheap, but they are if you get in for free with a media pass as I do because I’m also an author of these articles, white papers, eBooks and videos.

To get to the point of the proper cybersecurity presence, you can do one or more of the following 4′ things…

If you are a project-centric professional services organization – start with your business analyst or tech leads. In my opinion, this is probably the best way to start spreading the cybersecurity expertise to those who are most entrenched daily in the projects underway, about to happen, being planned and the customers they are working with. And it ensures that every project has a cybersecurity / cyber risk planning and management presence. That is priceless. And you have homegrown talent – also priceless.

Hire an outside consultant to review processes, projects and infrastructure and make recommendations. Expensive, but it can be a good start to building your own cybersecurity infrastructure. The expert will tell you what your needs likely are and help you plan a path to getting there including any re-organization and hiring you need to do today, a month from now and a year from now to be successful and safe. Expensive, but it will help the organization determine their real needs and how to get to the point of fulfilling those needs properly.

Hire cybersecurity talent and build a staff. If you are large organization handling sensitive internal or customer data, then you probably should have done this yesterday. So do it tomorrow and don’t procrastinate. And put a C-level security person in the organization – a CSO.

Hire an outside consulting organization to take part in necessary projects. Not your best choice for the money, but this can be a stop-gap measure if you find yourself suddenly immersed in projects that are highly data sensitive. As you move in that direction, the last thing you want is project failure and a big, highly visible data breach. So, if you must, then do this. It is far better than the alternative. And should something bad happen, it is far less expensive than the hack exposure.

Summary

Now is the time for action. Not tomorrow, not next year. Procrastination can cost millions in this instance. Train, buy, hire, or whatever… do something to protect your projects, customers and data.

Your Excellence Inspires Me

Written by Brad Egeland on April 17, 2019. Posted in Articles. 1 Comment on Your Excellence Inspires Me

I heard this the other day – can’t remember where.

But the concept of the statement is great. Someone is inspired to be better due to someone else’s excellence or perceived excellence. How would you like to hear this statement made to you? Especially from someone you know and respected. It would be great. What a boost. Perhaps almost life changing. If you agree then don’t be stingy with your compliments. You like how hard your kids are working on a task or chore? Tell them. The dinner taste great? Compliment your spouse or the chef at the restaurant. Service was good – tell the manager and single out your server by name. They usually get a bonus or gift card for that. A colleague puts on a good presentation. Tell them.

So back to being actually “inspired” by someone’s excellence. I believe we should all strive for this and work hard as if we might here those words at the end of a project. What is project management excellence? How would you define it? For me, excellent project delivery isn’t about a successful project as much as it is about our leadership of the project, team, customer and stakeholders.

As project leaders in the business analyst role how can we show excellence throughout the project and daily to inspire our team and our fellow business analysts and even our customer to raise their own bar of performance and quality? Consider these…

Lead by example.

First, lead by example. You will never inspire excellence in others if aren’t practicing what you preach. All the time we see this failure in fraudulent CEOs, our embezzling CFOs, our corrupt school leaders, religious leaders, and key political leaders in top spots throughout the United States and throughout the world. It’s frustrating, it’s unfortunate, and it makes it very difficult to know who to look up to and who to question. Don’t let that be you in a leadership role. I’m not saying I’m awesome by any means, but it’s always nice to tell my potential consulting and project clients that they can look me up on the internet anywhere and not find anything negative and that I’ve passed every background check and finger print check I’ve ever been through and there have been dozens as a resulting church leadership roles, background checks for adoptions and government project roles and for working in the hospitality and gaming industry. Be that business analyst who above reproach and people is won’t question your authority, your experience and your excellence. They will respect you for the leader that you are, they will follow you and you will inspire them.

Be completely transparent.

Always be transparent. Keeping information secret or hidden or unspoken that should be share makes you seem deceptive or duplicitous. It’s not the way to lead or gain respect. It’s not the same as lying but it sort of is. It’s deception by omission. If your team or your project customer finds out about something that is critical to the project and affects them by means other than your communication to them and you already knew about it, then they will always wonder what else you aren’t telling them. Losing trust is easy. Gaining trust is difficult. And keeping trust is hard when you are keeping important things and information from others. Getting trust back in some cases is impossible… then you lost that opportunity to inspire excellence in them forever. So be transparent. Share everything. I was once told by another business analyst working on a project with me that he really liked working on projects with me because he always felt like I was keeping him – and everyone on the team – as up to date as possible every day on the project. He said he received many more email updates and communications from me than he did from any other project team member or project manager on his other projects. I’m not completely sure he wasn’t telling me that I send too many emails, but over communication is good too and you ensure that everyone is on the same page, so I took that as a compliment. Be transparent. You will never regret it and it will inspire others to do the same.

Always plan well.

Exhibit excellent communication skills.

Communicate well and often. As with the above example, those working with you will appreciate knowing what you know and being up to date and will never feel like they don’t know the whole story. Effective and efficient communication – both outgoing and listening – is Job One for project leaders. It keeps information flowing for all, it keeps everyone on the same page, it is truly the best path to the successful project delivery and it earns and keeps the respect of others. By keeping your project team up to date at all times they will be accountable, feel appreciated, be a better project participant, and be more confident. They will feel respected and they will respect you for it. You will be inspiring excellence in them throughout the project engagement. And you customer will love it. No customer wants to feel like you’re keeping something from them. It grows frustration and discontent and you never want to go there with the customer. Or team member. Communicate well and often to inspire respect and excellence in others.

Summary

It all comes down to exhibiting best practices each day as we are conducting ourselves, leading our teams, leading our project customers, making decisions and leading our projects overall. Be a good leader, be honest and of high integrity, do what you say you’re going to do and keep everyone on the same page and you will have the respect of all those on the project with you. You will be portraying excellence by default.

Poor requirements can triple the length of the project

Written by Brad Egeland on February 25, 2019. Posted in Articles. 2 Comments on Poor requirements can triple the length of the project

Requirements are the lifeblood of the project. Period.

And bad requirements or missing requirements can triple the length of the project. Worse, they can kill a project altogether due to time or budget (or both) issues.

I just had a simple home project for my wife go south because I failed to get the requirements fully defined before starting. I thought I had everything right, but I made some assumptions without asking certain questions. Keep in mind she is my very organized wife who hates it when I ask too many questions before starting a project for her. But our project customers have a potential to be problematic, stubborn, demanding or even uncooperative, right?

Next project today I got detailed requirements and then clarified and asked a couple of questions. We were definitely on the same page. When the project was over an hour later – complete to the original specs (I thought, anyway) and I asked if this looked ok and she said “oh heck no.” This was an example of some customers who just can’t be pleased or impressed. You may have to cut them loose if this keeps happening, but in my specific case with my wife, of course, that isn’t going to happen… you get the picture.

So, what can we do to ensure this doesn’t happen / and to keep my wife from getting mad at me on my next home project? We can focus on these 4 things…

Schedule enough planning time.

One of the biggest reasons there are disconnects between what the customer wants, the requirements that get documented, and the solution your team builds is lack of enough planning time. Requirements are so critical – you really can’t spend too much time on them as long as it is reasonable for the project. But cutting corners on the requirements definition phase is a definite no-no. There is no specific yardstick on how long to spend planning and documenting requirements. I wish I could give you an exact formula and if I could I would probably be a millionaire. Initially, for a good-sized tech project that is going to last 6 months or more, I would put at least 2-3 weeks into the schedule with 3-4 dedicated meetings and several assigned subtasks. Understand that the window for documenting requirements may expand or contract – it will be hard to predict but you must document detailed requirements thoroughly and as accurately as possible. Period.

Ask more questions even if it may seem like too many.

The bottom line is this – we need to avoid bad requirements and mis-understood requirements at almost all costs. Extend the requirements definition phase out if necessary – even if it injures the project budget and timeline early on. That is far better than extremely costly rework later in the project that might also serve to triple the length of the project as suggested by this article’s title. Take more time to analyze, define and document requirements. Ask more questions – lots of questions – of the customer project sponsor, the subject matter experts (SMEs), the ultimate end users – anyone and everyone on the customer side that knows what they want and need from the solution. Complete requirements that are complex and detailed set the stage for successful user acceptance testing (UAT) as well as a well-designed end solution that will meet the users’ needs and bring a successful conclusion to the project engagement.

Repeat the requirements individually as they are documented.

This may seem either obvious or overly mundane – depending on the individual or personality type. And you can argue till your out of breath against it but if it saves even a few hours of re-work by 2 or 3 project team members that could be $10,000 of project budget saved just be clarifying a requirement out loud. It goes along with my stance of following up after every meeting with notes from the meeting to make sure everyone is on the same page. We all have the potential to hear things and interpret things differently and we all go into each communication incident with some pre-conceived notions and are therefore bound to come out the other side with some varying understandings. Repeat requirements – get common understanding. It’s logical… common sense. Most PM best practices are that logical. It’s not rocket science.

Review the full set of requirements before beginning any project work or next phase.

Once all the requirements for the effort are detailed and complete, the business analyst should schedule a 3-5-hour session (longer, if necessary – depends on the complexity of the project and the size of the requirements document you’ve assembled) to review and discuss the full set of connected requirements. Do these now make sense and fit together right to form the intended solution? I do this and have never regretted it. There has never been a project where at least five or ten key requirements weren’t missing some detail or omitted completely. On multi-million-dollar projects that may translate into a savings of $100,000 or more of re-work and lost schedule fixing what was wrong or missing. Again, this session is just good common sense… good communication and good management. Planning and documenting is critical, so is follow-up to ensure common understanding and completeness.

Summary / call for input

The bottom line is this – whether it’s a big 18-month tech project for a client you’ve known for two weeks or a two-hour Saturday morning project for your wide who you’ve known for almost 36 years, clarity and completeness in project requirements is critical. Anything less can leave you with lost revenue, profitability and time or on the home front… well that’s going to vary a bit with each relationship… but it could prove to be problematic for a couple days.

Readers – what are your thoughts? Have you had projects start with less than complete rand clarified and fully understood requirements? How badly has it affected your project revenue, profitability and timeline? Please share and discuss.

Real World Absolutes for Business Analysts on Tech Projects

Written by Brad Egeland on February 8, 2019. Posted in Articles.

Let me be the first to say that Project Management Professional (PMP) certification is great.

It can help you get hired, move up in your profession, and show dedication to your chosen career path. It can be a catalyst for cohesion within a PM infrastructure or project management office (PMO). It can give everyone a common language to use. It can show your project clients that the organization is dedicated to real success because your project managers are certified and ready to succeed on the projects they are managing for them.

While this is great – and I would never stand in the way of anyone’s certification aspirations… in fact I’ve helped hundreds follow that path already – it isn’t likely how you’re going to manage projects in the real world. I’ve been managing projects since shortly after the first PMP certification testing took place in October 1984. But in every organization I’ve been in and worked with PMP processes and concepts weren’t the norm or of any major importance – project success and customer satisfaction has been the emphasis and that isn’t likely to change. PMP is great to have, but it’s like algebra… you might not actually use the knowledge very much in real life. It may get you a $20k raise or a better job elsewhere earning more… no doubt about that. But usage will likely be minimal. It’s more of a paper and resume thing.

Gaining PMP certification is not likely going to change that much about how you manage projects or how your organization manages projects. It certainly hasn’t for the dozens of organizations I’ve worked with as an employee or as clients. I’ve experienced this personally, and I’ve seen it stated elsewhere that 98% of the day-to-day project management activities don’t require anything they teach in a course, as PMBOK and other frameworks often really only work best on mega projects when they are use. But when you run hundreds of small projects, all you really need are an organization, people skills, and common sense. The real skills that make or break a project manager is the emotional intelligence to know which tool to use at the right time, including a deep respect and appreciation for human behavior and group dynamics.

So, let’s talk “Real World” project management and business analyst responsibilities in that real-world PM arena. Yes, some of these overlaps with the PMBOK and PMP certification requirements, but let’s move beyond that and talk about what is going to be expected of business analysts in the world of day to day project management and leadership – in most organizations.

Client leadership.

Client leadership is a key responsibility of the business analyst. The project manager will oversee the engagement, status report on it, and be the primary and central point of formal communication on the project. But from a pure daily delivery team <==> customer communication standpoint, that will likely be the business analyst. Or at least it should be – if there is a business analyst assigned to the project. And I believe you should have a business analyst proposed on every project possible as they are needed as a key customer facing resource and as a leader of the tech team on the project. There are not enough hours in the day for the project manager to completely cover these two roles and most project managers are not prepared or experienced enough technically to fully serve the role of tech team liaison. The business analyst on a tech project would be – or needs to be.

Status reporting.

While status reporting is a key responsibility of the project manager, it will also fall under the responsibilities of the business analyst throughout most project engagements. Why? Because sometimes – in the absence of the project manager – they may act as sole lead on the project and at the very least will likely be somewhat of a co-lead throughout… though their leadership role is likely to be more informal and adhoc. Being able to create, update and lead meetings from a project status report will be one of their PM real world responsibilities.

Meeting facilitation.

The project manager on any engagement will lead many to most of the more formal meeting sessions like weekly status meetings, quarterly quality review meetings (if applicable), project kickoff meetings, lessons learned sessions, etc. But the business analyst is going to lead many team meetings and less formal – as needed – customer meetings to review information, customer requests, informal status updates and similar discussions. Meeting facilitation is definitely a real-world responsibility for the business analyst on the project. Know how to prepare an agenda, distribute in advance, take detailed notes and follow-up after the meeting with notes and information / results asking for feedback to ensure that all info is correct and that everyone has left meetings with the same ideas and on the same page. Anything else other than complete and common understanding for all participants can lead to re-work and missed deadlines and assignments.

Team leadership.

The business analyst will serve as the primary liaison between the tech project team and the project manager. To say they lead the team may be a stretch… as that overall leadership will fall to the project manager. However, day to day interaction, leadership and discussion with the project team will be a primary business analyst responsibility in real world project management. The business analyst – to be effective in his role – must possess and convey the leadership type qualities that demand a project team’s cooperation and respect such as honesty, integrity, follow-through and dedication to common goals and quality results.

Summary / call for input

I realize that this is just a few of the many real world and somewhat unwritten but understand responsibilities of the business analyst on any tech project engagement. These are mine from my own experiences on projects. Readers – what are your thoughts on this list and what would you add to this list from your own experiences? Please think about your own list from past projects and share with others here – let’s discuss.