Tag: Project Management

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.

Lessons Learned or Opportunities Lost?

Written by Paul Taplin on October 24, 2018. Posted in Articles.

Let’s say upfront that conducting a Lessons Learned process at the completion of a major initiative or project is a highly desirable and admirable thing to do.

But before you get too comfortable about the lessons learned process that you are about to manage or participate in, please consider some of the pitfalls that can plague the process.

Less is more

The measure of a successful lessons learned (LL) exercise is not the number of “lessons” identified but the relevance, quality and impact of the recommendations that you can pass on to future readers.

Three to five key recommendations will have far more impact than a two hundred line spreadsheet. The object of the exercise is to extract key learnings for future use on similar projects.

The LL exercise will undoubtedly generate a significant number of lessons, but these need to be reviewed and prioritised for your final output. Consider scoring the draft lessons to highlight those that are of sufficient importance and relevance to be worthy of inclusion. In the final analysis, discard lessons that are highly specific to your project, unlikely to be replicated, or items that are not supported by the majority of contributors.

The right participants

Ideally, participants should be invited to contribute from the broad spectrum of players who were involved at all levels in the project, from areas of strategy, planning, process and delivery. However, in inviting a democratic slice of players there are some behaviours that need to be understood and compensated for.

The strategists may want to concentrate on the politics and abstract aspects of the project, and ignore the nitty-gritty of implementation.

The planners and process people may want to concentrate of the efficacy of the process rather than the outcomes.

The delivery people, especially those that were deep within the delivery teams, may have a limited horizon, concentrating on specific issues that may only be relevant to that project.

So care needs to be taken in preparing the invitation list, facilitating the LL process, and generally managing the different perspectives that will arise from the roles and perspectives of each of the players.

Clear process guidance

A well-planned LL process will reduce the amount of time that is required of each of the participants, and also create a well-understood process that is psychologically safe for each of the players.

Generally, the LL process will include:

Identifying the LL process framework;
Identifying LL categories – time-based, process-based or output-based;
Seeking LL events for consideration;
Identifying for each offered event:
- A title;
- An explanation of the event;
- Possible causes; and
- Possible recommendations.
Gaining consensus from participants regarding the importance of the LL event, the causes, and the most appropriate recommendations;
Prioritising the outputs;
Preparing and publishing the LL report.

Psychological safety

The psychological safety of each participant is very important, as you want each person to “open up” and give their honest opinions without the fear that they may be ridiculed or castigated by other members.

Junior members need to feel that they are in a safe environment, and that their contribution won’t come back to haunt them at a later date. They also need to believe that their peers and bosses will respect their contribution during the workshop.

In this regard, the facilitator should seek an assurance from all the workshop participants that whatever is expressed at the workshop stays within those walls.

Participants need to be assured and should feel comfortable that final recommendations will be expressed in a manner that preserves the anonymity of each contributor.

Balancing positives and negatives

Unfortunately, there is a strong tendency for LL teams to identify and develop only negative LL events. This is because it seems to be easier for us to recall and analyse negative events rather than recognising the impact of positive items. Perhaps positive items are just taken for granted as the status quo? Perhaps also its because positive items tend to be related to processes with no emotion attached, rather than actual negative events that may have been emotive at the time?

It is extremely important to recognise key positive events or processes, as these will be invaluable to future readers. It is also a way to provide some balance in the recommendations, and to recognise and celebrate the successes.

If the positive attributes don’t appear to be generated during the early stages of the LL process, then the facilitation must include a specific reflective session to acknowledge key positive aspects of the project, and the extent that these should be published.

The final report should introduce the overall positive aspects first to illustrate that, in the holistic sense, the project or undertaking was quite successful, and why that is the case. (Except of course if the project was a total disaster, and everyone knows it!)

Avoiding recriminations

Unfortunately, a few participants may see their participation in the LL process as an ideal opportunity to criticise other individuals or “management” (commonly referred to as “they”), or to repeat their particular hobbyhorse, possibly to the exclusion of any other considerations.

So, participant selection is vitally important, and so is careful facilitation of the interactive process. However, the LL participant group should be selected as a broad spectrum of players, and some manageable level of antagonism may be a price worth paying to ensure that all relevant views and perceptions have been canvassed.

Optimising resource time

The most common approach is to invite players to participate in a workshop once the LL process and agenda have been developed. However, this approach can lead to a significant time impost for some of the players, especially key corporate executives.

Another approach is to initially seek suggested LL events, explanations and recommendations from players via a well-structured questionnaire, and subsequently to invite key players to a shorter duration workshop specifically to develop and agree key recommendations based on the questionnaire outputs. This approach also has the added advantage of minimising the opportunity for interactive personal recriminations.

The questionnaire approach can work extremely well in a busy environment, although it will require more preparation time from the organisers and the facilitator. Another approach involves interviewing time-poor senior executives in their offices, or by phone, and adding their contribution to the workshop, but again this requires more time from the facilitator.

Publishing and archiving

Apart from any cathartic effect that a LL process and report may have for its participants, really the key objective is to pass on relevant recommendations for future readers who are about to embark on a similar project or undertaking.

Therefore, it’s important that the report is concise and eminently readable, incorporating key recommendations in the body of the report formatted in a manner that future readers will retain. All supporting information should be relegated to a series of attachments.

The manner of archiving is also critical, and since most organisations now use some form of information management system (IMS), the LL report will need to be appropriately tagged and stored for easy retrieval.

Guaranteeing future readership

It’s not really sufficient to rely on passive retrieval techniques via the organisation’s IMS. All LL participants should informally monitor the organisation’s activities, act as advocates, and be prepared to offer relevant reference material and links to future players when the situation arises.

Get the most out of your meetings: brush up on your facilitation skills

Written by Rohela Raouf on October 16, 2018. Posted in Articles. 1 Comment on Get the most out of your meetings: brush up on your facilitation skills

Business analysts are meant to be good at facilitating, it’s meant to be one of our key skills.

However, speaking to many of the BAs in my network, facilitation is the one area that they feel that they can do more. I guess one of the difficulties with facilitation is that you don’t always end up with a tangible outcome. This then makes it harder to determine the value in what you have achieved. No, one wants to go a two-hour meeting, where they sit around the desk and discuss the same things over and over again. Often, people state that they find meetings really unproductive and go far as to say that they are blockers in getting things done.

I disagree with this, I recently attended the IRM business analysis conference where the keynote speaker Clive Woodward (famous rugby coach) stated that he couldn’t work out why people didn’t like meetings. I agree with him, meetings are meant to be a tool and if the tool is not being utilised productive manner then it becomes more of a people issue. Instead of blaming the tool, ask yourself if it is used in the most productive manner.

So, to avoid your meeting become stale and boring, we have created some top tips to get you to think outside your comfort zone for meetings. I am not going to state the obvious like making sure you have a set agenda for your meeting or defined outcomes that you want to achieve. As, a business analyst, I would expect you do this for any meeting that you facilitate.

Tips

1. Try a new type of meeting format – Lean coffee

• This is one of my favourite type of meetings. So, if you have not done this before it is quite an easy concept to follow. Everyone in the meeting writes on a post-it note, items that they want to discuss. Put the post-it notes on the wall. Carry out infinity sort, to understand if there are any key themes that have come out around what people want to discuss.
• Pick the most popular item- if you don’t have one then I would pick one at random. Discuss that item for a period of 5 mins and then ask everyone if they want to discuss it further after the first 5 minutes. If, yes discuss for another 5 mins and so forth
• Top tip- I would recommend not discussing anything longer than 15 minutes- I personally find after 15 minutes’ people start becoming disengaged with the subject matter. If you have not received a conclusion after 15 minutes, I would suggest you move this to the parked section and come back to it at a later stage if you need to. It is important that after 15 minutes, you move onto another topic- avoid talking for the sake of talking.

2. Pick a different location

• Unless you work at Google, your office will be a typical office- bright artificial lights if you are lucky you will have lots of glass or if you’re not then you will have white walls. If you are always meeting in the same location, then by human nature you tend to associate that space with certain emotions. So, if you have meetings that are lacklustre people then tend to associate that emotion with the meeting rooms that you have in office.
• So, once in a while go out of the office and go to the local coffee shop to hold your meeting there. Change of scenery is great, as it gets people to think in a different way. Also, walking to the local café will get people energised, as will the fresh air.

3. Observe where people are sitting

• If you have regular meetings, you will notice that people either sit in the same chair or they will sit next to the same people. By sitting next to the same person, you will end up inevitable. people embracing the same role each meeting. To avoid this happening. Mix it up a bit in your meeting, I am not suggesting you create a seating plan for your meetings. What, I am suggesting is that you gently steer people to sit in a different position.
• Top tip- if possible move the furniture around the room, this will naturally force people to sit in a different seating position to their usual. Also, make sure you are sitting in a different place to your usual seating position.

4. Give the dominated person a task

• We have all been in meetings, where there is one person who talks all the time. I would suggest, with that person give them either a flip chart pen or whiteboard marker and get them to make note of what everyone is saying. By, having to write they will naturally be focused on listening to everyone in the room. If that is not possible, then I would suggest you get them to read the actions from the last meeting. By giving them this role, you are getting them to focus on the other people in the room and the role that they place in the meeting.

5. Avoid multi-tasking

• Ban smartphones and laptops at meetings. When people are working on multiple things at the same time, they are not able to give 100% to either of these things. To avoid having semi-interested in people – ban the laptops. In my team, if we have a team meeting then everyone has to leave both their phones and laptops at their desks. This means people are more invested in the meeting and by having them more focused in the team discussion you are more likely to get a decision quicker.

So, next time you are going to facilitate a meeting, try one of the above tips and see what difference it can make to your meetings.

Making the successful transition from business analyst to project manager

Written by Brad Egeland on September 6, 2018. Posted in Articles. 1 Comment on Making the successful transition from business analyst to project manager

Not all project managers want to manage projects forever. Sometimes they look to switch to a more technical hands on position with the team like the business analyst role.

Likewise, not all business analysts want to continue in the role of business analyst forever – looking to take on a higher level management commitment of the project and deal less with the daily team and customer oversight that the BA role is usually responsible for on most project engagements.

If you are considering a move to project management from business analysis, below are some of the key areas where – in my opinion – you’ll need to take some extra steps or will need to focus efforts on in order to make the transition as successful as possible as quickly as possible. I’ve limited it to five areas – please consider and share your own thoughts that come up as you read this.

Training and certification.

If the business analyst is truly certain about making the transition to full on project management then a good start would be to go through the proper training and certification. Getting your project management professional (PMP) certification is the likeliest best route to take. The applicant must document the proper amount of experience to sit for the exam but there many places that can assist you that and even get you trained and certified within 5 days – with a 100% guarantee that you’ll pass it and if you don’t you get to take it again door free.

Learning the software.

Yes, there will be software involved. It’s 2018 and you’re not likely to manage a project over 100 hours without using more than an Excel spreadsheet. Whatever software tool you prefer or your new project manager colleagues recommend or your organization (or customer) requires you to use, learn it and use it. They are all fairly similar and you mainly want to be able to input your tasks and their scheduled dates, connected the dependent tasks, add resources to the tasks and associate costs to those resources. Once you’ve done that, you should be ready to go.

Thinking at 10,000 feet.

As a business analyst, you’ve probably been used to viewing tasks and requirements and business processes and design issues at very minute detailed levels. As a project manager, you do care about the details, but you have to get used to looking at most things – most of the time – at the 10,000 foot level.

Meaning at a very high level and analyzing the overall affect of tasks, task progress, issues, resource input, and task dependency, etc. at very high levels and how they affect the project now, a week from now, a month from now, how they affect each team member and the customer, and sometimes even how they affect other projects.

Making decisions.

The business analyst is always making decisions – probably just as many or more than the project manager that are important to the project. The decisions being made are often different – with the business analyst making decisions focused on – for tech projects – next design and development steps, requirements definition and interpretation issues and similar. The project manager is often more focused on making higher level project related decisions like task assignments, resource changes and needs, delivery dates, vendors to be used, etc. So the nature of decisions that the business analyst making such a transition will change and they must be comfortable making those decisions – sometimes quickly with less than enough information and possibly with no team members or stakeholders or even the customer available to provide input that may be needed for more project critical decisions.

Communications and meeting facilitation.

The business analyst making the transition to project manager must be a master communicator as it is jib zone for the project manager position. Communicator and meeting facilitator go hand in hand. It’s not enough to just disseminate information. You also need to be. A great listener, understand what’s being communicated and understand what lies behind and beyond the communication. Sort of interpreting someone the communication as it comes through because there can be some meaning to it that lied below the service. As far as meetings, it’s much more than calling an meeting to discuss a topic. Ores planning for the meeting, getting meeting info out to meeting attendees in advance Sao that they have time to prepare for what may be expected of them during the meeting to aid in information dissemination, project update, and decision making. And them taking great notes during the meeting f

Summary / call for input

Project manager. Business analyst. Both are leaders. Both must be excellent communicators, meeting facilitators, team leaders, decision makers and customer managers. But in slightly different ways. Each role prepares you well if you are interested in transitioning to the other. Perhaps the business analyst to project manager role is easier because you’ll already have that more hands-on technical feel that isn’t absolutely necessary for the project management role but can make life easier. The project manager making a move to business analyst may need to acquire that skill set and it may not be easy depending on the background the project manager is coming from. It’s my stance that every project manager leading tech related projects should have a technical background. Being a former application developer and application development manager has helped me in my project management and consulting roles in many ways and legitimizes my skills and understanding of the technology to tech project team that may not be the easies to manage from the outset and rarely trusts the non-tech project managers out there who try to give them direction.

Readers – what’s your thoughts on this? Have you made the transition one way or another? Was it easy? Hard? What about your experience in one or the other helped most with the transition? And was the move permanent or did you take it slow or go back? Please share and discuss.

Calling All Business Analysts: You are the Wave

Written by Brad Egeland on August 22, 2018. Posted in Articles. 2 Comments on Calling All Business Analysts: You are the Wave

Sort of like the straw that stirs the drink. Stealing a line from one of my favorite songs from one of my favorite bands… “In the middle of the world on a fish hook, you’re the wave.”.

Interesting twist, I always think. Gavin Rossdale, the main song writer and the frontman of the band Bush, is the writer and singer of these lyrics from the song “Swallowed” and he only talks about the world and the fish hook, yet he doesn’t call the subject of the song any of either of these. He refers to her as the wave that makes the world and fish hook bob erratically. Interesting way of thinking outside the box for these lyrics and the perfect way of expressing this concept.

A basic, boring definition of a business analyst is this… “A business analyst (BA) is someone who analyzes an organization or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology.” But does that really sum up what you’re doing if you are a business analyst? Is this what you tell your friends or is it go a lot deeper than that. I’ve been a project manager for many years and my business analysts certainly juggle more than can be described or extracted from that generic definition.

Let’s wrap this up so my point becomes clearer. The business analyst is not the people in the middle – that’s the project manager, the project customer, the team. The great business analyst is really doing much more and in a way is “directing” the project – or being “the wave” that causes some of the most important tasks and processes on the project to connect and actually happen. They cause them to move forward. They do this mainly through these focused activities or project responsibilities…

Daily team touch base.

The business analyst is going to be the main touchpoint or contact for the individual project team members. It won’t be like that on every project and that can vary from organization to organization, but certainly a solid business analyst is expected to be the main contact on a team level throughout the engagement. It doesn’t have to be formal meetings, but checking in with the entire team is common and even providing the team with a daily status update for the project. The project manager should also be doing this – likely at a higher level and this business analyst daily call out could just be an add-on or resend with more detail or updates to that daily PM communication.

Liaison between project manager and team.

Certainly this is probably the most common overall activity that people think of when they consider especially the communication duties of the business analyst. On a tech project that business analyst will be the one throughout who is seeking out any further necessary discussions of or detailed definitions or clarifications of specific project requirements, getting and giving project status updates to the project manager and team and ensuring that smaller details aren’t falling through the cracks.

Frequent customer interfacing.

Likely no one on the project will interface with the customer as much or as often as the business analyst – even more than the project manager. While the project manager will focus more on organizational and status activities with the project customer, the business analyst focuses more on project dynamics and what’s going on at this instance sort of material and communication on the project. Requirements questions and clarifications, business process details, and anything that the tech team comes up with that needs to be asked of or passed along to the project customer.

Help the project team interface with the project customer.

To go a step further in clarifying part of the responsibility in that last item, the business analyst is going to be the primary point of contact between the customer and the individual project team members. Too much team communication between the customer and each individual project team member can lead to miscommunications, ever changing requirements, gold platting by a tech team member in over developing the project solution and an overall lack of focus for the team doing the daily project work. There needs to be a central point of contact – especially on tech projects – and the business analyst is that central contact point.

Daily touch base with the project manager.

Likewise, the business analyst will be in frequent communication with the project manager as each will likely serve as the other’s go to project person. Overall project communication responsibility will always be Job One for the project manager, but it isn’t far off the mark for the business analyst as well – both must be excellent and efficient project communicators, master project meeting facilitators, and great customer interfacers. Planning project next steps, key project communications and making joint decisions will always be part of the collaborative interactions that happen between the project manager and the business analyst on the engagement.

Summary / call for input

The bottom line is this – while the project manager is the person with the big red target on their head and holder of overall project responsibility and communication duties, the business analyst is at least their equal in all that – albeit often at a more daily, casual and even more frequent level. It is a more common situation to see a business analyst onsite with the customer 80-100% of the time than it is the project manager, who’s duties can mostly be performed from a distance. Often the business analyst is going to be in more daily contact with the customer and team and probably making even more key decisions over the life of the project than even the project manager is making. They are the “straw that stirs the drink,” or in this case they are “the wave.”

Readers – how do you feel about this concept? Do you agree? If you are a business analyst, do you feel like “the wave” in the middle of a world on a fish hook? Please share your thoughts and discuss.