Tag: Team

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 Project communication mistakes.

Written by Matthew Pountney on June 28, 2018. Posted in Articles. 3 Comments on 5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest.

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’.

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.

3. Creating an information vacuum, allowing gossip

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups.

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation.

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

The DevOps Business Analyst Conundrum

Written by Raji Pillay on June 21, 2018. Posted in Articles.

Them: What do you do?

Me: I am a Business Analyst with DevOps

Them: Huh?

Them: How does that work? Who are your stakeholders? What exactly do you do?

This is a typical conversation I end up having every time I mention my role.

Let me start by answering a few questions that I have been posed with over my term as a “Business Analyst in DevOps”.

What is the role of DevOps in Delivery?

DevOps is anything but a buzzword. The term has picked up a lot of attention in technology and for the right reasons.

DevOps bridges the gap between teams that have worked in silos in the SDLC. Continuous Integration and Continuous Delivery enhances Agile delivery model. This allows delivery to ship code in smaller chunks continuously. It accelerates the shipment of code to production.

Some examples that I have worked with in DevOps:

Architecture changes/upgrades as part of delivery (eg: upgrading your out of support SMTP server)
Implementation of new tools to aid in delivery (eg: monitoring tools like Splunk, appdynamics, use of jenkins)
Supporting the non-prod environment
Designing deployment pipelines
Integrating early testing in the pipeline
Delivering robust features

And most importantly cultivating the DevOps mindset across delivery and operations!

Yes, tools are important to achieve the end goal, but we cannot progress without an inherent cultural shift.

Who are the stakeholders for a BA in DevOps and What does a Business Analyst need to consider?

Higher management, delivery team, testing team, operations, and your own self: they are all your stakeholders. The idea or requirement to improve the development, delivery, testing or operation of the application can come from anyone.

The essential core role of a Business Analyst doesn’t change with projects or genre of requirements. The same applies to a Business Analyst in DevOps. The below examples will shed light on projects that BA’s have to work with where the DevOps tools and mindset is required.

a) One-click deployment: This requirement came out of the extensively manual deployments we had to perform as a team. This meant constant monitoring and having someone manually go from one step to the other. Like any other process, the less the manual intervention the less the chances of human mistakes.

Stakeholders:

Operations team (Actual Deployment team)
DevOps Team (Creating the one-click pipeline0
Delivery team (to provide inputs)
Senior Management

Things to consider as a Business Analyst:

Understand the issues in current state that the operations team are facing.
The ripple effects and the issues this creates for the releases.
The advantage delivery team will have going forward.
How can this be built to add automated testing and blue/green deployment as an iterative approach?
What tools will be required to deliver

b) Migration to cloud: With the sweep of infrastructure migration to cloud, this is a prevalent project in many organizations. Rightly so! The migration can be small-scale lift and shift with only the APIs or queue endpoints in the cloud, or it can be a large-scale migration.

Stakeholders:

Management (the directive and timelines come from them)
Solution Architects ( The solution and design will come from this group)
Project Managers
Performance Team
Functional Testing
Security Team
Database Administrators
DevOps
Delivery
Operations
Third Party Vendors if any

Things to consider as a Business Analyst:

Work with the solution designers and business to understand the use cases
Start creating epics to manage scope and prioritize
Break down the high-level design or epic into smaller chunks of work with the delivery teams
Incorporate security and Non-Functional Requirements as part of the use cases being delivered
Work on data migration strategy
Work with Testing teams to create functional and regression testing plan
Engage relevant stakeholders to work out operational readiness, DR strategy, and final cut-over strategy

c) Business Requirement (feature/functional driven work): Delivery of a business functional requirement. This piece of work involves as much a DevOps mindset as the above-mentioned work. In the delivery of features, we need to consider the BAU support required for the non-prod environments, the work involving the deployment of the code, the delivery of non-functional requirements. All this done with the “I am not working in silo” mindset makes it as much DevOps as any other work.

This is a snapshot of the things that a Business Analyst needs to consider. It is not an exhaustive list.

What skills does a BA need to be a part of DevOps?

A Business Analyst needs all the tools from his/her toolkit and experience gained over the past to navigate the DevOps world. However the most important is the mindset for continuous delivery, integration, continuous deployment and a keen understanding and importance for the non-functional requirements.

Whether it is in a titled “DevOps” team or a feature delivery team, this mindset will ensure we consider “Reliability” “Performance” “Security” and “Stability” as a feature instead of nice-to-haves.

The role of a BA is then to help deliver world-class platforms, as always.

The core of being a Business Analyst doesn’t change weather we work with a traditional waterfall methodology, an Agile framework or an Agile DevOps framework. In fact, a DevOps mindset is required in any of the frameworks that we work with. It is essentially considering NFRs as a feature and delivering them continuously in collaboration and continuously along with the functional business requirements.

I hope this helps answer the Business Analyst in DevOps conundrum.

Joining the dots: Working with an Agile development team

Written by Nick Stowers on June 14, 2018. Posted in Articles.

I’ve read lots of articles and books on Business Analysis tools and techniques and when to use them in the project lifecycle.

What I haven’t seen so much of is how the BA works with the different roles in an Agile development team. My previous blog went into the change for a BA working in a Waterfall framework to Agile which touched on this subject, so here I want to delve in to how you use the tools and techniques we all know so well and how you work with the right people to ensure the outputs from those techniques are effective. It’s based on the British Computer Society (BCS) Foundation in Business Analysis course headings for those who have that certification.

Investigate situation – uncover issues and problems

As we know, this stage is about understanding what the problem is. The techniques are used mainly in a Discovery phase and is very heavy on stakeholder engagement. However, the skills you use are very closely linked to those of a User Researcher. Interviewing techniques may sound very simple and straightforward but for those who have tried it, it’s not easy. Understanding what are open and closed questions and picking out the important information from the other ‘noise’ is difficult. When interviewing to stakeholders, It’s very easy to:

Lose focus of the interview (go off track)
Not make the most of the time you have with the interviewee and end up with follow up conversations
Not get all the information you are after (again, resulting in follow up conversations)

Working with a good User Researcher, they will show you how to go about creating an effective discussion guide that allows you to not only maximise the time you have with the person you’re interviewing, but also capture all the pertinent information you need in one go. Stakeholders are busy people and may not want to be contacted numerous times.

If you have Subject Matter Experts (SME) as part of the agile team for the Discovery stage, then you will be spending quite a bit of time with them to understand the ‘As is’ processes. Don’t just use them for information though, get them involved in articulating the problems, whether it be a rich picture, mind map or emotion map. Making them feel part of the team will build relationships that you might need to call on later in the development of the product.

Consider perspectives – stakeholder identification and analysis

Getting to firstly identify the stakeholders for your product/service will involve most of the development team on board at that time. Typically, this will be a Product Owner/manager, Delivery Manager (Scrum master), User Researcher and SMEs.

Stakeholder identification and analysis (e.g. interest/influence matrix) sessions should be carried out with the whole team but the BA should be working closely with the Product Owner to understand those stakeholders in the high interest/high influence category which you will need to be managed. While you may not be directly involved in engaging them, you will need to understand their perspectives as they may well see some of your outputs (e.g. problem identification, cost/benefits analysis)

Analyse needs – identify improvements

After the Discovery phase is completed and you’ve got the go ahead for Alpha, now it’s time to get (for me) in to the exciting part of product development……identifying potential solutions to problems.

This for me is the part of product development where the BA really starts to put in practice the work they’ve done in Discovery and develop those relationships with nearly all of the other roles on the product team. Let’s start with prototyping solutions.

You’ve now worked with the user researcher to elicit user needs, engaged SMEs and stakeholders to understand ‘as is’ processes, identified potential pain points and have a list of stakeholders which you are keeping an eye on and managing (ideally with a communications strategy). While all this was going on, the interaction designer/UX will have (or should have) been working on a prototype to meet some of those user needs (not all of them, this is Agile after all). So where does the BA fit in here then? Well, first of all, as you were involved in eliciting those user needs through your interviews with stakeholders (including users), you want to ensure what the UX is designing meets those needs (and not just something they think is a ‘good idea’. To be fair, UX rarely, if at all, do this). Some BA books will say the BA would create prototypes however, in these days of software development, many organisations now specialise with either a UX, interaction designer or variation (be careful here. I’ve worked with someone who got very irate when I referred to him as a UX when he was an interaction designer!! There is a difference by the way)

Now a prototype’s been developed, you (along with the UR) are taking it out to users to test and get feedback. Again, it’s a skill that you will learn from a good UR. Trying to stop yourself showing a user how to use a prototype is hard……we’re inherently helpful but need to constrain ourselves and see what the user does.

When you feedback the findings from the testing to the rest of the team (a must), you will be asking the developers and QA what possible constraints there may be (if any) if a particular solution was to be implemented. At this stage, you can start engaging the QA to find out how they want the scenarios articulated in the user stories (e.g. are they happy with BDD). This flows nicely in to the next stage.

Evaluate options – High level user stories

For a lot of people, this and the next stage (Define requirements) is where the BA comes in to their own because it’s about user stories. It’s worth pointing out here that if you haven’t begun to understand the rest of the team roles, it makes the last 2 stages a lot more difficult. Remember, you are building relationships and understanding with your team, and the sooner you do this the better it is….for everyone. I’ll come to why a little later.

As the prototype has been tested, some of the design hypotheses will have turned in to proven user needs i.e. the user likes what’s been designed and is ‘good to go’ to be developed in to a ‘thing’. Great, we can at last start writing user stories! I’m not going to cover that subject here as there’s more than enough information out there to cover how to write good user stories. What I will cover here is that you must involve everyone on the team in the creation and elaboration of those stories…. from start to finish. Don’t see the user stories as purely ‘the BA role’. It probably is to write them but they’re actually the whole team’s user stories. There’s nothing more frustrating than spending time and effort creating what you think is the perfect user story only for the front-end developer to say in 3 amigos that the design has changed, or an API has been removed/changed resulting in functionality having to change.

Making the whole team aware of the story, not just the Developers and QA, is a way of managing risks and ensuring the unknowns are kept to a minimum. You’ll never stop all unknowns but you can cut these right down when everyone on the team knows what the story’s about. After all, the BA can’t be expected to think of everything!

Define requirements – User stories

I’ve briefly covered user story development but here is how you take that to the next level and become the linchpin of the development team. One of the most important tools I’ve used on all my Agile teams is the user story map. Jeff Paton has written a great book on the subject (which I’m sure you’ve all read) however, my main issue was getting it implemented. I’ll cover how I overcame this in a later blog but for now, the user story map is not just a tool for displaying user stories. it’s a vehicle for getting the whole team involved keeping the product on track to achieve its aim. As we know, the user story map not only shows a flow of stories from left to right (user journey) but also top to bottom (releases). It gives a short(ish) view of the work of the team but if you add in the designer’s hypothesis board and the product vision, it provides a flow from design right through to development. It’s also a great tool to use at show and tells. It really gets the stakeholders engaged. Much more than a boring set of slides.

I’ve joined many teams where they haven’t had a user story map in place (they’ve normally just got a sprint board) and I find the whole team’s disconnected. The designers are working on something that’s either not part of the product roadmap (if there is one) or they are carrying out user research that developers are building in the next sprint leaving no time for the BA to carry out the analysis of the story. In a nutshell, everyone has a different view of the product’s vision resulting in different priorities and actions. A recipe for disaster.

As Business Analysts in an Agile world, we need to focus on not only building relationships with our stakeholders, but with the team who’s going to develop the product. Not only is this an essential role of the BA, I would argue it’s critical to the success of the team.

Is Overtime an Issue for You?

Written by Neal Whitten,PMP on May 15, 2018. Posted in Articles.

Working overtime hours can be a testy issue. Let’s look more closely at the subject of overtime.

Question

From a business perspective, how should overtime work be viewed?

Answer

Overtime work is often thought of as a safety net to ensure that work—especially committed work—gets done with the sense of urgency required so that the business thrives. Rather than temporarily hiring employees during peak work periods and laying them off when the workload subsides, businesses usually prefer that core employees meet the business need by working overtime.

Question

Do most organizations or companies view overtime similarly?

Answer

Every organization has its own culture. Some organizations don’t want their employees to work any overtime except in rare cases—and some of those cases would require approval from the employee’s boss. Some organizations pay their employees for overtime work. Some organizations are subject to union rules. In my experience, most organizations rely on and expect some overtime from their employees in order to meet their business objectives.

Question

How much overtime is a project member expected to work?

Answer

The short answer is: However much it takes, within reason, to get the job done. Understand, however, that the point is not to work more hours, it’s to get results. These results can be related to fulfilling your commitments or to meeting business needs that might surpass your commitments.

Question

What do you mean by “however much it takes—within reason”?

Answer

The answer will vary from company to company and depending on the situation. But in general, an employee may work as much as 10 hours a week of overtime—sometimes for many weeks or months at a time. However, if you are working more than 10 hours per week of sustained overtime, something may be amiss. You might be overloaded, you might require additional training, you might have unproductive work habits, you might be in the wrong job, or you might want to work the extra time because you love your job. Talk with your boss and PM if you feel you are working too much overtime.

Question

Are you saying that I should never have to work more than 10 hours of overtime in any given week?

Answer

No, I am not saying that. In fact, sometimes your overtime may exceed 10 hours in a given week, depending on the importance and urgency of the issue at hand. However, long-term, it is strongly preferable that a project member not be required to work more than 10 extra hours on average per week. Doing so could contribute to “burnout,” personal hardship, and other negative outcomes.

Question

What if someone wants to work more than 10 hours of overtime each week? Would you allow it?

Answer

Probably, as long as no government or company rules are being broken and there are no safety, health, or security concerns. An employee who’s eager to make progress may get passionately caught up in a project. I respect that and can relate. If there were insufficient funding available to pay for the additional work, then I would work with the employee to find some other means of showing my appreciation. Examples might include giving her time off, funding to attend a relevant trade show or conference, an award, special training, a highly visible position, or a quicker promotion.

Question

I have heard that working overtime causes a person’s productivity and quality to suffer. Has this been your experience?

Answer

It depends. Some people might be less productive and might make more mistakes while working overtime if they are distracted by non-work-related thoughts. On the flip side, I believe many people who are highly motivated and focused are capable of excellent productivity and quality while working overtime. For one thing, they might get “on a roll” because they are able to concentrate on their work with fewer distractions than they would experience during normal work hours. Of course, working excessive overtime for a sustained period can negatively affect almost anyone’s performance.

Question

I am quite productive and can almost always get my job done within the standard work week. Do you believe that not working overtime is hurting my career?

Answer

Perhaps. You may be achieving the expected results based on your job level, but working overtime can help move the business further than it would go if no one worked overtime. And project members who are willing to go the extra mile are more likely to open doors to greater opportunities and promotions.

Question

Then are you saying that I am wrong to avoid overtime—even though I am able to get my job done within the standard work week?

Answer

It is not a matter of being right or wrong; it is a matter of choice. I cannot overstate the importance of an employee achieving what he believes is a healthy balance between his personal and professional lives. Naturally, the more we dedicate ourselves to something, the likelier we are to receive the recognition and rewards that go along with those achievements. It is a matter of personal choice.

Question

Then are you saying that working overtime is good for my career?

Answer

It depends on why you are working overtime. If you are working overtime because you made a mistake or are unproductive, then doing so might help you save your job. If you are working overtime to achieve more than is expected of you or because you volunteered to “save the day,” then, clearly, it will help your career.

Question

Should overtime be planned into projects?

Answer

On longer-term projects, no. On very short projects with a sense of urgency for the deliverable, yes, if overtime is appropriate to meet the business needs. Overtime is one form of buffer contingency. If overtime is planned into long-term projects, then those projects are at greater risk of failure to meet commitments. But for an urgent project that might be only days or weeks long, all project stakeholders might be asked to rise to the business need.

Question

When there is overtime on a project, is it a sign that one or more people have “messed up”?

Answer

Not necessarily. Projects can be quite complex and every project is unique in terms of technology, interpersonal relationships, budgets, business needs, client expectations, and so many other factors. Even on a “typical” project, overtime may be required as project members approach a major milestone and scurry to achieve the date on time. Of course, overtime can also be the consequence of having overzealous sales and marketing folks, inadequate or misunderstood requirements, poor estimates, weak planning and tracking, weak leadership, and a host of other ills.

The best-run projects, by the way, are not necessarily those that finished without overtime being required. Businesses should strive to constructively and consistently get employees to achieve a healthy level of productivity. Some overtime may be inevitable.