schoolin'

It's a bit of a change of routine for me this week and I spent a chunk of my afternoon under exam conditions sitting an exam in the company of an independent invigilator.  I'm doing a course, you see.  Two courses, actually.  Both of them industry standard British Computer Society courses with an actual qualification at the end of them both -- subject to exam results, of course.  By the time we get back from Canada in three weeks time, I could be the proud owner of a shiny pair of new qualifications for my CV - Foundation and Practitioner in Business Analysis, if you're really interested.

It's been a bit of an eye-opener to study the absolute nuts & bolts of my job and to see quite how far my company has drifted from any recognisable industry norm.  To be honest, it's impossible to study this stuff and not to wonder how on earth I'm going to be able to take it back and apply it in my day job. Data modelling? Soft Systems methodology and User Perspectives? It's all pretty basic stuff, and we simply don't do any of it, thinking that we can jump straight into detailed requirements and then wondering why our requirements aren't very good and don't represent what the business actually needed.

This is probably a bit dull if you're not really into project lifecycles - and honestly, what kind of person really is? - but apparently some 80% of project defects can be traced back to the requirements phase... but on average, only 12% of project time is spend actually gathering and documenting requirements.  At my place, I think that time we spend in requirements is much shorter even than that.  Only last week, our director stood up in front of everyone and specifically said how we needed to be spending days on requirements and not weeks.....

I've learned what seems like hundreds of new techniques in the last couple of days, and I've discovered that even the ones that are deemed to be the most basic and essential to the whole process are not recognised or understood by my own department.  CATWOE?  We don't even acknowledge that there is a need for conceptual systems modelling in the first place, never mind understand what is apparently the number one technique for any BA.

Ironically, the reason we've had the chance to do this training is under an initiative called [*sigh*] "Delivery at Pace", specifically "Requirements at Pace".  And what are we learning?  That we need to spend much, much MORE time on the analysis phase of projects and not less.  It's been a brilliant course and one I really could have done with doing years ago... only I didn't appreciate either the gap in my skills or how easy it was to fix.  Still, better late than never.  It's a good course and it's been a really interesting, stimulating week so far.

My boss is a champion of this Pace initiative, and has been busy advancing his own career by blowing smoke up the collective arses of the Leadership team about what this will mean and how much more quickly we'll all be working.  Oh, we'll be working a lot more efficiently and delivering a much higher quality of output, for sure.  But faster?  No.  It just doesn't work like that as we'll simply have to be doing more work to make sure we capture this stuff right.  You invest time here to save time and money later in the project lifecycle.  It's really simple and is proven.  If you think otherwise, then you clearly don't know what you're talking about.

Ah....

You know you can rely on me to break it to my boss gently and tactfully when I get back into the business.  He's a toxic idiot who understands nothing.  Is that sugaring it up enough, do you think?