Do you feel valued and respected for what you know and do?
Do you feel unappreciated or undermined?
Is the training and development budget for you and your team realistic?
Are your testing estimates always negotiated downwards?
Are you involved in new projects/software releases from Inception or not until Development is under way?
At various times in my career I have felt under-valued, unappreciated, undermined and not respected. I’ve also struggled with a less than optimum training budget. In almost all cases I have had to either defend or cut my original estimates. I have on many occasions been engaged far too late in the SDLC to be truly effective.
It seems to me that these are challenges that we should NOT have to face on a regular basis. Our profession has formally existed for over 50 years and we are still challenged regularly to justify our existence. Maybe this is one of the main reasons why we defend our position within the SDLC so vehemently. After all, when you feel as if you are under attack you generally respond in a similar way – strongly. Every action leads to a corresponding reaction.
So, is it an acceptable state of affairs or should we be doing something about it? I believe it is our responsibility to resolve these challenges, in order that those who follow us can reap the benefits.
Challenge No. 1: How to gain respect and feel valued (for what you know)
Respect should be earned, not expected. Respect can takes years to gain and seconds to lose. Respect needs to be gained at all levels within an organisation, but if you aim high (the CEO is a good one) then the rest of management will usually fall into step; however, this approach will almost certainly result in jealousy from your peers and wariness from your team.
In my experience it is best to start at the bottom and work up – this means gaining the respect of your team first, then your peers and other department heads, followed by senior management and board members (if you need to go that high). Now some of you may think that I’m aiming too high, but I can assure you that when I have access to very senior managers and/or board members, my job becomes instantly easier. These people can make issues go away very quickly and make life far more comfortable for you and your team. The flip-side of this though is that when you mess up, your reputation becomes much harder to restore – so, don’t EVER mess up…
Gaining the respect of your team comes from making their job as easy as possible and understanding their day to day challenges (in order that you may help solve them). Gaining the respect of your peers comes from keeping promises and delivering on schedule. It’s also about giving bad news early – if something isn’t going to happen as planned then tell everyone involved as soon as you know. No one likes surprises, least of all management.
The great news is that, if you deliver on these items, you will also feel valued.
Challenge No. 2: What to do if you feel unappreciated and/or undermined
Appreciation is not something that’s easy to measure and not something that individuals need to the same extent. Some folks require constant reassurance, while others just need the occasional feedback. If you are one of the people who needs the former, then make sure your manager knows this, because not all managers are switched on to your needs. If you’re one of those people who just needs occasional feedback, then you’re fortunate and shouldn’t have this problem anyway.
Feeling undermined comes form a pretty similar space to unappreciated (psychologically). Those who feel undermined usually lack confidence in a situation. If you haven’t prepared sufficiently or done your homework it is easy to feel undermined when the outcome you were hoping for fails to materialise. If a Project Manager appears to undermine your position, it’s probably because you haven’t provided sufficient information for their needs – I’ve worked with hundreds of PMs and their levels of competence and approach has varied enormously. In my experience the ones who appear to undermine Test Managers are the ones who feel least confident themselves (either in their own work or yours). Many of these PMs don’t have a great grasp of what we do (or what Testing is fundamentally). Therefore assessing PM capability and understanding early is essential for all Test Managers.
Challenge No. 3: How to deal with an unrealistic Training Budget
First things first, I assume you have the opportunity to negotiate a Training Budget, because if you don’t you are not being given the chance to succeed in your job as a Test Manager. So, NO budget, is obviously also an unrealistic budget.
My concept of unrealistic has to be contextual, in that some years are harder than others to schedule, so I take a three year period when looking at Training and Development. My expectation is that 30 days of formal training and development are required for each three year period. This means that peaks and troughs in activity can be catered for in almost any organisation. I know some organisations are in constant delivery mode, but if this is the case then my approach is even more relevant.
Not all training and development has to cost money (although it will always cost time). Having said that, I am aware of several organisations in Australia that believe that training and development should be conducted in ones own time – outside client billing hour!! This is a whole different argument and one I will address in a future Blog.
The concept of “no/minimal cost” training and development comes from being creative. This typically involves in-house courses or vendor-sponsored breakfast/lunch sessions. There are also a myriad of online offerings that come at no cost. Twitter is also a growing source of excellent free training and development materials (I’d like to think this Blog is seen as a training and development aid).
Challenge No. 4: How to gain acceptance of your Testing Estimates
This is another contextual challenge. We have many types of SDLC, many business and technical environments and a multitude of business models; however, in my experience the same rules apply in all situations. Be prepared to do lots of preparation and planning, capture relevant statistics as you go (for historical reference purposes), gain support from your peers prior to estimate submission and build in contingency based upon how far away from software delivery you are estimating.
Estimating has proved to be one of those elusive challenges that many of us struggle with and because if this I am going to dedicate a complete series of future Blogs to this subject. For now though, lets deal with one of the basics – recognition and acceptance of realistic estimates.
History is the best indicator of future outcomes, if you undertake similar activities on a regular basis. Daily, weekly, monthly, quarterly software releases should be the easiest to estimate, as you should be able to identify common patterns in these cycles and work on an agreed basis. It’s the irregular projects that become hazardous… This is where statistical models from previous projects will help. If you don’t take the time to capture statistics then you are taking a very short-sighted approach to software development. If you don’t capture overtime and out of hours effort then you are also in trouble.
My basic rule is to keep everything as simple as possible (no different from my approach to everything), so that there are as few “moving parts” as possible. The less complex the process, the easier it is to explain and gain acceptance. Tools like mind-maps, to support your estimates, are also invaluable, as you can group your thoughts and processes logically.
Challenge No. 5: How to deal with late SDLC Engagement
The majority of Test Managers, that I’ve worked with, will say they can never be involved too early in a project; to this I say “bullshit”!! I have been engaged (on several occasions) far too early in the SDLC. The reason I say this is that when scope is not locked down it is almost impossible to plan, let alone prepare and construct testing artefacts. You can strategise and do high-level estimates, but engaging others to assist you is just wasting time and money. I recently watched a Test team spend almost 9 months re-working stuff due to a client not locking down scope – and then the client asked where all the money went!!!
Joining the SDLC at an “optimum” moment in time is almost impossible, so if I have the choice I’d rather join slightly early than slightly late – as long I have control over the rest of the Test team joining. I say this because I like to get the “feel” of a project before the rest of my team come on board. It also means that if I am going to have control over selecting the team I have a much better chance of picking the right mix of skills and personalities.
In my experience the only way to deal with late engagement is to lock down our scope, risks, issues, dependencies, priorities and outcomes ASAP, so that we can focus on the most important stuff from Day 1; in other words, a classic Risk-based approach…
Dateline: Tuesday February 19, “somewhere over the Indian Ocean” (returning to Oz)