If You Want to Be a B.A., You’ve Gotta Love Data

I am frequently surprised when I meet Business Analysts who don’t have much knowledge about databases, why they’re structured in different ways for different purposes, or even how to write a select statement.  I think as analysts, we have to take some of the blame for this happening, but I also think that non-IT businesses who have an IT group often pigeon hole business analysts firmly in business and don’t foster in their BAs a need to understand data, database architecture, or any other data skills.  That’s a shame.

As Business Analysts, we work with the business teams to understand the business, the conceptual objects that are created by our business and the processes that affect them.  We also should understand how the data in the business is used today and have some ideas of how that data could be used to greater advantage in the future.  As we work on a project, we do discovery on what elements of information are needed to complete a business task.  We should understand how those information elements relate to each other and how they are comprised of various attributes.  Working through analysis on a human resources project will almost invariably ask you to create an object to represent a person.  How that person is related to an employer, other employees, benefits packages, payrolls, etc. is the stuff that data design is made for. 

Most IT shops have DBAs who will assist with the creation of tables, relationships, indexes, and all else that goes into creating the data infrastructure that supports a product.  As BAs, we are not likely to be asked to do that work ourselves.  I put it to you, however, that you must know the concepts behind data design and architecture so that you can work together with your DBA in a meaningful way.  You are going to understand the nuances of information interrelations.  You will have a good idea of what elements are most important, which data will be most frequently referenced, so you have valuable insights that will help the DBA do their jobs more effectively.  As a B.A., you can definitely add value in the data design phases of any project.

During discovery and data design, you will use data modelling.  Data modelling refers to the creation of a description of how a database is or will be structured and used.  Some common models are: Flat, hierarchical, relational, and object-relational.  These models allow you to quickly and efficiently convey to others how what objects are important in your business process and how they relate to each other.    Entity-relationship models are a very useful means to communicate those relationships.  You should also be aware that individual items of data have their own properties.  Is it a numeric field?  Is it a text field?  Is the value stored in this field always one of a predetermined set of answers?  If you don’t have a sound background in data modelling, there are many wonderful ways to learn about them, from taking a class in person to participating in a class online.  You can also find many, many websites on the topic as well as books. Please look at the end of this article for some links and suggestions.

Once you’ve conquered the art of working on the design of a database, you need to be able to work with the information.  You need to be able to recover it and manipulate it.  You need to be able to pull out pertinent information from several tables and combine the results.  For this, you need SQL.  As a BA, you need to at least be able to construct a select statement and give it criteria upon which to select and a way to sort the data.  Ultimately, it would be handy for you to know how to create a complex selection between several tables and store the results into a temporary table.  You should also understand how to update, add, and remove records.  These basic skills are relatively easy to do, once you know the ins and outs of data and relationships.  SQL script is relatively natural and easy to work with.  It just takes time and practice.  You also need a data base that you can completely muck up and not cause a problem.  If you can do that, you will be able to help your team test your software, set up specific scenarios for “what if” testing and create reports that will benefit your stakeholders.

Again, there are tons of resources out there that are free or moderately priced.  Go out and find a book about SQL. Don’t get paralyzed in choosing which “flavor” of SQL to use.  Your employer has probably chosen their database technology, go with it.  Or, you can use an open sourced database manager and learn from it.  SQL for Oracle is not drastically different from SQL for Microsoft or an open sourced system.  Making the effort to learn and being rewarded by the warm glow of learning will reinforce your effort.

You may have noticed that I haven’t even started a rant about understanding data flow within and between systems.  That’s a whole other article.  Be prepared.  Until then, happy modeling.

Resources

Coursera is a wonderful source of learning.  Courses are developed and delivered by major universities.  There is little to no charge to learn.  Visit www.coursera.org to learn more. 

EdEx is another free to low cost option for folks looking to learn about many different topics.  Visit www.edex.org and search for topics to get started.

SQLcourse.com offers an interactive SQL learning environment.  It’s pretty nifty in that you can actually interact with a SQL interpreter to do your practical work.  www.sqlcourse.com

Microsoft Virtual Academy has free on-demand courses for beginners to advanced folks.  They’re set up so that you can create lesson plans for yourself and they feed in to MS certification, if you want to go that far.  Here’s a link to the English SQL Server Courses: https://mva.microsoft.com/product-training/sql-server#!index=2&lang=1033

A great choice is the “For Dummies” series.  Do not discount these books for learning.  Amazon.com has almost every version you would want.   You can also get these books on Google Play.

The O’Reilly series of books (the ones with the interesting animals on the front) are consistently well written and very useful for different levels of users.  Amazon and Google Play are good sources.

Conflict, Growth, and Turning Pain into Growth

A co-worker of mine has a phrase up on his whiteboard.  “There is no growth without conflict.”  He loves that quote and works with the people in his influence to get them to embrace conflict as a healthy thing.  We’re not talking knock-down, drag-out fights, we are talking rational debate and maybe a bit of passion for the work.  My friend has embraced conflict, but so many of us spend time trying to avoid it in our work lives and in our private lives.  As a result, we may be restricting our own growth as employees and as human beings.

It is very natural to want to avoid “pain’.  Even non-physical conflict can result in painful feelings.  We get that twist in our gut, that headache, that tension in the back.  We all know those feelings, but we may have not put them to work for ourselves.  We may not have recognized those feelings as an invitation to be open and honest about why we are feeling those things and openly and honestly working through them internally or with the people with whom you are in conflict.  Because we gloss over those feelings, they can stay with us, festering and building up until you just can’t take it anymore and a really big painful event erupts to throw things completely off kilter.  You may have experienced this in your work-life, when you’ve flown off the handle after some seemingly small point of contention sends you over the edge.  We have all felt this happen in our personal lives, I’m sure as well.  Instead of avoiding that pain and paying dearly for its cathartic release, I suggest letting it trickle out as it comes up.  Speak your mind and communicate with compassion and honesty in every setting, even at work.

When you fail to express your disagreement during your work-life, you are generally giving in to someone, like your boss or a team member.  When you fail to rationally express your disagreement, you are hurting yourself, the team, and the company.  What if your idea really is better?  What if both your ideas stink, but there is a better one out there that you can find together?  You’ll never know, if you don’t express yourself.  Innovation definitely will not happen if you keep things to yourself.

In the business world when we are developing solutions to problems, whether they be in people or electronic processes, it’s very, very important to speak out if you don’t agree with things that are being accepted as true or if you disagree with a solution.  Even if you are on the business side and you’re disagreeing with a technical resource or a superior in your organization, your disagreement is important.  There is a reason you are feeling “pain”.  It may be that you see a fault in their logic.  It may be that you know how the people in the field work and the proposed solution will cause too much disruption and not enough value for the company to invest in it.  You may have a better idea, you may have a worse idea, but you will never know unless you bring it up.

Tension between the business and technology implementation teams is inevitable.  We’ve probably all seen instances where our business sponsors have asked for a warp capable starship level product but have given you the timeline for building a canoe.  (Hyperbole for fun and illustrative purposes).  That is frustrating and aggravating, if we are honest.  Maybe the timeline is there, but the budget for R&D isn’t.  Whatever the conflict, it is up to the technical team to speak out about it.  The business may not be aware of the complexities of what they’re asking for.  It’s just a warp drive starship.  It’s just a website.  They may not understand that the security behind the site and authorization model for the different roles is going to take a long time to work out and to program and test. You as a technical team member must make sure they understand the pain point.  If they do, then they can rationally think things through and perhaps change the budget, give you more time, or start scaling back on their initial expectations.  They may be fine with a canoe at the outset.  They may be fine with the reduced, minimal feature set to start out with.  You won’t know if you don’t tell them your pain and explain why you’re experiencing it.

As a business analyst, I have frequently come to development teams with the business’ requirements only to be told that can’t happen or that what the business is asking for is silly or not needed.  Talk about a pain.  As the representative of the business, it’s extremely important that I understand the pain points that are driving the technology request and the value that is behind those requests.  I need to understand what is essential and what is negotiable.  I need to be able to articulate that to the development team and work with them to relieve the pain they’re feeling so that we can come to an agreement on the solution, given the needs, resources, time, and technical architecture we must work within.  All that discussion, all that conflict will cause us to re-examine things, ask tough questions and generally come up with an innovative solution that will benefit everyone involved.  You won’t get that innovation if you don’t speak up for the business.  You won’t get that if you fail to speak up for the technical team.  Rational, open, and honest conflict will pay off.

Do you notice how I’m always using the words rational, open, and honest?  These three features define a healthy debate.  Being rational is essential.  The word, rational, is defined as “being based upon or in accordance with reason or logic”.  Rational conflict does not become personal.  It is not about you or them.  Rational conflict looks at the facts, the requirements, the environment and all the other factors that surround a project.  There may be some gut feelings involved from time to time, but in general, that conflict and gut feeling are based upon what is known and what the future state must be in order to realize value from the work you will be putting in. 

Open and honest debate means that you are open to other ideas and express your ideas in ways that allow for debate, allow for you to be wrong, and allow for the middle ground.  Being open means you put all your ideas, concerns, and solutions on the table.  It also means being vulnerable.  Learning cannot happen unless you open yourself to the idea that you may be wrong, the other guy may be right or there is a better solution somewhere in between.  You may take a hit on your personal pride, if your reasoning is flawed or you’re basing your argument on a fallacious assumption, but how can you find out if you’re wrong and grow as a result of learning if you don’t allow yourself to be open to that possibility?  Sure, it will sting for a while, but you will get over it.  Other people will forgive you for speaking your mind and being wrong, especially if you’re open to saying “Oh, I’m wrong.  I didn’t think about that.”  In fact, your “street cred” will likely go up as people gain respect for you.  You will also be reinforcing an environment where people can be open about their conflicts and therefore encouraging personal and team growth.  Honesty is crucial here as well.  As business analysts and as human beings, we should never play games to make a political or personal point.  Being honest about a disagreement allows that pain and conflict to come to light and be addressed.  Being dishonest and creating conflict is definitely a path to destruction but being dishonest to avoid conflict is also a short road to an even bigger conflict down the road.  If you know something is wrong, if you see a flaw in logic, even if the gut feel is wrong, you should express yourself openly, honestly and rationally so that everything can be worked out.  Innovation is going to happen in that working out of the conflict.  Growth will happen when you realize that you were both a little wrong and you find the way to make each of you all right.

I’d like to close with a personal story about learning to embrace change.  I have worked on projects where everything seems to be going fine.  You’re chugging along and suddenly, something fundamental to the project changes.  More often than not, the timeline contracts.  Sometimes resources are diverted to other, hotter projects.  Whatever the reason, things are suddenly up in the air.  I used to waste time griping and wailing about the change.  I’d be sullen and quiet about all my concerns about it. I would start to feel awful about my workplace and my fellow co-workers because I blamed them for the pain of the upheaval.  Sometimes I got to say I told you so, when things went wrong, but that was a hollow victory.  When I learned to speak up an say my piece and take my ego out of the equation, I found that I had a lot less pain, a lot more respect for myself and others and I really believe that I and my coworkers started to benefit from my speaking out.  Now, I still have to coach myself to speak up in some situations, but it is much easier now.  I know that my rational, open, honest feedback will serve a purpose and build value for me, my team and my company. 

I swiped the image at the start of this article from Tim Rettig's excellent post about what to do when a team is in conflict.  He gives excellent advice on how you can rationally come to a solution.  Read that one at http://timrettig.net/7-steps-to-take-when-there-is-conflict-in-the-team/

Three Critical Competencies

I was talking to my husband about work the other day and reflecting upon other similar conversations when I had an epiphany.  It was one of those "It's so obvious" moments.  Whenever there are deep and continuous problems with a workplace, a product, or a project, you can boil everything down to a deficit in one or more of these things:

1.    Communication

2.    Trust

3.    Leadership

Failing to have a good communication strategy for any effort is a fast track to tragedy.  In order for any group to effectively work toward any goal, they have to understand what that goal really is.  They need to know why that goal is valuable to their organization or to their customer and how they can individually contribute to attaining that goal.  More importantly, they need to know when a change comes along, what that change is, and why that change is valuable.   Furthermore, the leaders of any effort must be able to effectively communicate to their customers.  Without a clear establishment of expectations for delivery of a project or product, the client can create a fantasy of what they're getting and build upon it as the effort progresses.  Those unrealistic expectations are not likely to be communicated to the work team until the product is presented to the customer.  Then the fruits of your organization's labor are met with a luke-warm reception, if not open hostility due to your having missed the mark, as far as the client is concerned.  A constant flow of information between work teams, leadership, and customers is crucial.  If a group's leaders founder in their communications, they will be met with confusion, frustration, anger, and resentment from both sides.

Trust is a three way relationship.  Not only do team members need to have trust in their leadership, leadership must have trust in their team members.  Open and honest communication about an effort is instrumental in building trust.  The communication must flow freely within a work group, both up and down the leadership ladder.  If team members do not feel like their leaders want to hear honest assessments of the situation, a decision, or an issue, they will shut down communication.  Leaders will then find that they are the last ones to know about problems.  They will not have input from their best advisers on the project, the people who are doing the work.  The work team whose leader does not trust them will not get the full picture of what they're trying to accomplish.  The team may not even be given an understanding of the scope and interrelationships of efforts and so make fallacious assumptions about the work and further undermine both their trust of leadership and leadership's trust in them.  To carry trust even further, the customer must be able to trust that they are getting what they have asked for and what the team has promised to deliver.  Setting realistic expectations and communicating constantly about status and deliverables will keep trust alive between the customer and the supplier.

Leadership is a quality some believe comes from a title.  This could not be further from the truth.  Leadership is seldom given and is almost always developed organically.  Work teams will naturally start to look toward those individuals who express a clear vision of how things are.  They will respect and follow the person who they feel is giving them the opportunity to succeed by providing key information on what is to be done, the goals for doing work, any supporting information, and honest acknowledgement.   They will follow the person(s) making decisions they feel are well considered and take account of different perspectives.  If a work group's managers or other leaders dither rather than decide, the team will feel rudderless since they have no definite goal and no rationale for that goal. Output will suffer and a joint effort will experience thrashing as different factions start working to their own agenda which likely will be divergent.  A more insidious risk lies in the team starting to follow poisonous leaders who can and will crop up in work groups with a power vacuum.  There is always the possibility of a person within a group who will be critical of the project, the organization, and/or leadership and offer themselves as the person speaking the truth about the situation.  

You MAY be able to limp along with communication and leadership alone, but your team(s) will not be as engaged as they could be.  Trust is the glue that binds teams and keeps them working harmoniously together.  Trust breeds frank communication of issues or risks because the team members feel that they can say the hard and unpopular things without fear of retribution.  They feel valued and invested in the work being done.  They have some skin in the game.  That's why I believe that you really must have communication, leadership, and trust in any work effort in order to succeed together.

Agendas - Everybody Needs One

I did a PowerPoint presentation on this some while ago and thought I'd transfer it to blog format.  Everyone seems to "know" the value of agendas but still, we all get invited to and, worse yet, set up meetings without them.  I'm guilty.  I will admit it.  We are all busy and we all are crunched for time.  I put it to you that one reason for that is wasted time attending meetings with no direction or output expected.  If we had purpose for every meeting we attended, I'm willing to bet we would not feel so pressed for time.

Agenda: n. a list of items of business to be considered and discussed at a meeting; a list or program of things to be done or addressed.  Derived from the Latin agere, which means "to do".

Agendas are about getting something done.  Whether it's making decisions, informing others, or producing an actual product, the agenda establishes expectations of completion when all is said and done.  When was the last time that you felt like the bulk of time spent in a meeting was productive or walked out of a meeting feeling accomplished?  When was the last time the converse was true?  Did either instance of meetings have agendas? Did the poor meetings use and follow their agenda?  Having and using a good agenda can help assure success and give all attendees the sense that the meeting was time well spent.

Why do you, as a meeting organizer need an agenda?  Many folks feel like they don't need an agenda.  They may feel that it cramps creativity or doesn't suit the purpose of the meeting.  Can you think of a meeting that doesn't need an agenda?

I believe that having an agenda makes sure that everyone understands why they are there in that room and what they are expected to do.  It gives them a level foundation upon which all participants can build and do the work at hand.  It allows them to focus upon the expected output for the meeting and get things done.  People won't waste time wondering why they are there and should give enough freedom to let creativity flow.  Further more, it allows a team to know when they've accomplished what they needed to get done, because they know what that is.  If a meeting does not have an expressed outcome, it is impossible to know if you accomplished anything.  If you know what you have to do, it's even possible that you can finish early and get back some time in your work day.

Meetings without clarity of purpose cost employers big money, when you look at the cost of everyone's time.  If they produce nothing, it's time wasted and money wasted.  Meetings without a clarity of purpose reinforce the attitude that meetings are not real work.  This results in people arriving late, skipping the meeting entirely, or disengaging from the task at hand by fiddling with their cell phones, doodling, or daydreaming.  No one comes to work to waste time so workers in fruitless meetings become frustrated and disengaged further from the work.

Agendas set the stage for success in the short and long term.  You know you should never embark upon a project without a plan.  Treat each meeting as a mini-project and have your agenda (plan) ready. You will be surprised at how well people start regarding your meetings.  If you give people a clarity of purpose, they will place a value on them.  They will stop dreading them.  They will stay engaged during the meeting, feel like they are contributing and generally be more engaged in the project.

A good agenda sets the plan for success.  A bad one will leave people adrift and may result in the failure to accomplish the meetings goals.  Being realistic is critical to meeting success.  If you try to cram too much into a meeting, it will fail.  You must also be sure to include everyone that is required to do the work to be done.  If making decisions, you will need to have all of the decision makers there.  You will need to present all the information, options, or ideas for consideration.  You will need to make time to hear from all of those at the meeting.  If you don't need to hear from someone, don't invite them, or make them optional attendees.  In your agenda, establish roles and responsibilities for attendees, as needed.  Advise them of these roles and responsibilities well before hand, so that they can prepare.  If you fail to do so, your meeting will come to a screeching halt and you will have an upset team member on your hands.  Time box your meeting, assigning time for each segment of the work.  Doing so gives you a tool to move the meeting along.  Stick to your timings when appropriate, but recognize when the team needs to extend a segment and let them do it, but remind them of the impact.  Start and end your meeting on time, with allowances at the beginning and ending to allow people to arrive from other meetings and depart to their next one.

Because time is money, invite only those people directly participating in or affected by the outcome of the meeting.  This is especially important for working sessions and decision making meetings.  Give attendees as much time to prepare as possible.  They need to get their work and their thoughts in line to contribute.  Be sure to communicate roles and responsibilities early too.  That way your attendees are prepared to do what is expected of them.  Also, inform the participants of the format of the meeting and the ground rules, especially if you are asking them to be active within the meeting.  By making sure that everyone knows why they're there and how to prepare and participate, everyone will provide value that will get the work done.

Remember, agendas set the stage for success.  They help the work team focus on what is to be done and ensure that the task is completed at the end of the meeting.  They help people understand their roles and the reason they are invited and they provide a plan for the activities to take place.  In the end, they're the checklist that helps you, the facilitator, know that you've guided the team to success.

Stress, Relief, and Benefits

Every single person I have worked with, as a BA, battles stress and anxiety.  Really, anyone in I.T. has probably experienced an acute case of either or both once in their work career.  How we handle stress is important.  It's important to us, as individuals.  We need to take care of ourselves so that we don't get sick or burned out in our jobs.  Acute stress and anxiety in a team are counter productive and can destroy a team, if it carries on long enough to become chronic.

I personally believe that we American Adults are not generally well taught how to handle stress and anxiety.  We are told to buck up, shake it off, and/or cope.  No one ever tells us how to do those things.  As a result, we just carry stress around with us as it builds and builds until you either have an explosion or you just burn out and stop caring, stop trying, and freeze up.

I believe that is why there is suddenly a great interest in Yoga, Tai Chi, meditation, and other disciplines which aim to make us more aware of our bodies and our minds.  They also generally focus on relaxation even in the midst of exercise.  This focus on relaxation in the face of doing new and sometimes challenging things is instrumental in helping a person learn to calm themselves and relax when in the presence of stress.

With this in mind, I have made it a goal to practice Yoga and yoga-ish exercise every day.  I have blocked out time in my workday (no more than 15 minutes) in order to unplug and do some yoga.  I also have the intent to do this type of break at home.  Now, it's not possible to be able to do this every day; we get smothered in work or sick, or just have no will.  Here's the important part, THAT'S OK.  What could be more horrible than heaping more stress upon yourself for not doing your de-stressing practices?  The thing that I am striving for is the concept of perfection.  As I am a mortal being, living in the mortal world, I will never reach perfection.  That's fine.  As long as I am always moving toward it and looking to the hope of future improvement, I'm reaching my goal.

Maybe we all should find our de-stressor, un-stressor, anti-stressor; pick your term.  Then, allow for that activity every day. It needs to be something small, that doesn't require a lot of special equipment or preparation.  Something that you can do upon need and at regular intervals.  What is your best way of relaxing in the face of stress?  Only you can find out.

If we can obtain the goal of a less stressed work environment, collaboration and innovation are more possible.  Those positive energy activities cry out for an unstressed environment.  Therefore, I am coming to believe that an unstressed workforce is a collaborative and innovative workforce.  I'm not saying that there should be no challenges.  I am saying that having a high level of stress on a continuous basis works against those two essential business needs and is therefore highly detrimental to any organization experiencing it.

What are your thoughts?

You Are A BUSINESS Analyst

I am a Business Analyst.

What I do is so much more than the title implies.  Systems Analyst doesn't do it justice either.  In my line of work, you must either know the business inside and out or get the skills that allow you to elicit a client's needs, wants, and pain points quickly and with a deep understanding.  Furthermore you need to be able to take those items and translate them to features and functions that the development team can create, inside the known framework and architecture inside your organization.  You need to know the up-stream and down-stream impacts on other systems and you also need to plan for the future.  When you put it all together, it's an intimidating amount of knowledge and skills.  At the end of the day, however, it's the business and their needs, wants, and pain points that drive our jobs as Business Analysts.

I have heard many great and not-so-great technical team members grousing about "If it weren't for the stupid users, our jobs would be so much easier."  In my youthful cynicism and life as a developer, that was something I could get behind.  I just wanted to get the software done. All these wants and needs and nitpicking was holding up my ability to deliver.  As I have gotten more experience and a well rounded sense of what it really takes to build good software offerings for my clients, I have come to realize that internalizing that statement and making it your battle cry is a short road to failure.

If you sit down and really think about what we do as I.T. professionals in general, it should be a very short while before the truth smacks you in the head like the cold fish of reality.  Our jobs exist, our careers exist, and really our technology exists, expressly to support the day to day processes which are needed to run a business.  Sure, a business could try to function in this day and age without technology, but I believe even the smallest of businesses would struggle to survive and definitely struggle to grow without some investment in I.T. to support and promote them.

Too often, we techie types forget these important concepts.  We just want to get the job done.  We lose sight of the fact that without the business, our jobs and our very skill and knowledge wouldn't exist.  The earliest analog computers were not created as an abstract exercise.  The Antikythera Mechanism is the earliest known analog computer that helped compute astronomical positions and therefore aid in ships' navigation.  This navigation was not undertaken for fun.  Around A.D. 100, sailing great distances was a very risky commercial and/or military activity.  Knowing where you were at any given time was the difference between loss of a ship and its cargo or a successful commercial venture.  Having the ability to understand where you were going was the difference between reaching the beach on the shores of your enemy or accidentally invading the shores of your closest ally.  When the people who built this device, and others like it, sat down to work on them, you can safely assume that business and/or military interests were on their minds.  They had to take into account all the issues and concerns associated to them while designing their mechanism.  Otherwise, their mechanism wouldn't have served any purpose except of an idle curiosity to play with and then set aside.

As Business Analysts, it is imperative to remember who drives your work.  You must listen to and empathize with your business.  A good analyst will sit down and watch users or potential users in order to see what their day is like, what matters to them, and what would make things easier.  A good analyst will work with the business to find the underlying problem(s) that are driving the request that put you there in the first place.  A great analyst will work with the business to determine and understand how best to solve those underlying problems and what mode those solutions should take.  A really great analyst will know when to suggest non-technical solutions that the business can implement with less risk and definitely less cost.  Any analyst worth their salt should then be able to take all their good business information and work with the technical team to design an efficient solution to meet all the needs and wants for the business.  Through out all this, the analyst will be an advocate for the business' interests.  Most importantly, they will realize that all of these processes, wants, and needs are the space in which your job is made.  It's where you add value for the business and help to ensure that it not only continues to function in today's world, it grows and thrives in the future.

I will grant it that there are folks out there who design write elegant code for their own satisfaction.  However, if they are paid for doing so, you can bet there was a business problem and a business process behind it all.  Remember, analysts, the business is your reason for being a Business Analyst.

Finding A Sense of Urgency In A Relaxed Environment

Finding Urgency in a Relaxed Work Environment

I am one lucky duck.  I work for an incredible employer who values each and every one of its employees.  We work in a relaxed environment where the I.T. professionals are treated well and where our business owners know our worth.  Not only that, they are a part of our teams, resulting in a high level of trust between the business and the technical sides.  That in and of itself is a rare occurrence.  Sometimes I think I’ve reached employment nirvana.

Other times, however, I have been beset by a nagging little voice.  That little voice probes and pokes me when I review our backlog or talk to our product owners about future product plans.  I can’t help but wonder “Are we moving as fast as we can or should?”

A little background here.  I come from a series of workplaces where I.T. had little to no control over timelines.  I come from a background where I.T. resources were treated as highly interchangeable assets in a cost center.  We could be replaced with little to no fuss or muss.  The business drove our timelines and I.T. was tasked with fulfilling their requests at the timeline specified or risk being replaced.  As a result, we were driven to work at a fast and furious pace.  As you may expect, we never lacked for a sense of urgency bordering on fear.

Coming to my new employer, I experienced prolonged cultural shock.  The pace at my new employer proceeded much more gracefully and I.T. was able to negotiate with project/product ownership to determine the timelines (unless they were driven by regulatory compliance).  This is when I started hearing that little nagging voice.

The sense of urgency that I was missing was mostly of my own making.  I was so accustomed to having the hammer hanging over my head, I didn’t know how to act without it.  I perceived my own work and those of my co-workers as proceeding at a snail’s pace.  I didn’t like this state of being, nor did I think that I or my team members deserved my own harsh judgement.  I had to find that urgency in the relaxed and respectful environment I found myself inhabiting.

To do so, I started by looking at the business.  I thought about what we deliver to them.  As an I.T. team, we deliver business value.  We may not directly make dollars for the company through selling our software, but we provide value to our company’s position when we give them quality software that meets their immediate business needs.  Therefore, it is extremely important to do the very best job we can to understand not only what they are asking for, but the context underlying the request.  It’s also important to understand what client requests and feedback is driving that request.  Often times, we can start coding early on and perform the requirements gathering as we work.  This can be costly, as requirements discovered later rather than sooner can cost time and money, and maybe even a client’s business.  I found urgency in the need to do the best business process analysis and requirements elicitation as early as possible. 

Next, I looked at the technical discovery and design process.  I wanted to work with my team to create rapid prototypes at a very low cost.  I pushed for use of wire frames and even hand drawn workflows to test out workflows with little to no developer time needed.  If these prototypes failed, it would be a matter of hours at most to revise them and present them anew to the client.  I found an urgency in failing rapidly with cheap prototypes rather than wasting developer time in creating a solution only to have it rejected by the business at a late date in the project. 

Finally, I looked to testing.  How could we as a team perform testing in a more efficient and time-frugal way?  I started looking at my own testing and how I may have been overlapping with the testing provided by our more than capable QA team.  I talked to the QA in my own team and discussed the matter with other Business Analysts.  This introspection and questioning helped me and channel my sense of urgency and help my team and the QA folks find opportunities for improvement.  It was incremental value, but value none the less.

My search ultimately led me to understand that you don’t need looming and unrealistic deadlines to have urgency.  You don’t need the looming specter of a highly competitive employee review process to drive you to new levels of heroics.  Urgency is there all around you to find.  Continuous improvement and reflection on how we work individually and as a team can fulfill that need.  Understanding the business drivers and the wants and needs driving requests adds to that sense of urgency and the need to please the customer, the team, and yourself.