Fix yourself before you fix “the process”

At last week’s SQuAD conference, Danny Faught spoke about Tearing down the Ivory Tower of Testing.  As I understood it, the Ivory Tower is a box that you create around yourself or your department that essentially says, “I can’t work effectively unless….”. In response to false expectations and a fear of failing, we create processes, procedures, software development lifecycles, templates, and tools, all with the purpose of asking someone else to do something before we’ll even think about their project.

The reality is, that as IT professionals, we can provide value in a lot of different situations and with very minimal input.  Processes and best practices are less important than good thinking.

Oftentimes we create Ivory Towers with the best of intentions.  In the best of cases, we are trying to fix situations that caused failed IT projects.  In the worst of situations, we have preconceived (and incorrect) notions of what our role is and how it should be done that we are trying to force on our workmates and organizations.

You might be in an Ivory Tower if (and, yes, I’ve been there, done that, and bought the t-shirt in some cases):

• You find yourself referring to the process as the problem.
• You consider your detailed plans (test plans, requirements management plans, implementation plans) as a contract with someone about what you will and will not do, instead of a living document that facilitates communication about what you can do, given certain situations.
• Your list of “entry criteria” is longer than the list of services or deliverables you’ll provide.
• You believe that someone else on your team is deliberately trying to make the project fail.

If you find yourself in an Ivory Tower, your goal, should you choose to accept it, is to climb down, jump out, or tear apart the tower wall by wall.  Consider the following ideas to get you started:

• Clarify your mission.  Ask your manager what should be the key outcome of having you on the team.  This is important…oftentimes we build towers to protect ourselves from expectations that do not exist.
• Start assuming the best in others.  More than 9 times out of 10, your workmates are trying to create successful projects, just like you.  Talk to them. Take a look at the world from their point of view and understand their problems. Take a look at the “BAs are Difficult People” post for some ideas on this one.
• Humble yourself. Remember that no one in an organization is truly irreplaceable.  If you got so frustrated with your situation that you left tomorrow, the organization would most likely march on without you.
• Try to uncover complex reasons for the status quo.  Your organization or development process did not invent itself.  Good people (with good intentions) built it to solve specific problems.  Understand why.

The list could go on, but the point is to fix yourself and your relationships with your workmates first, not the process.  More than likely when you start moving in this direction, the problems you saw with the process will dissipate.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. How to align stakeholders around project scope without a requirements review and sign-off process
2. Managing chaotic situations by building “the list”
3. Can we elevate constraints in the requirements process to encourage creativity?

Tagged as: featured