When it comes to IT project management, what is the difference between “tunnel vision” and “focus”? I guess the obvious answer is that the former is what other people think we have and the latter is what we think we have! Seriously, though, I am sure there is a serious element to this question as I have heard it several times over the years.
I recently heard a senior business manager say “eight out of 10 project managers are useless.” This surprised me because I’ve done my share of project management over the years and worked with a great number of project managers, and my experience would suggest that a vast majority are very good at what they do. So why is it that this particular manager had such a bad experience?
Now that the Christmas roast and mince pies are well digested and we are brimming with vigour as we embark on crisply written resolutions I thought it would be a good idea to kick off the year by talking about requirements.
With awareness now high about the amount of total project budget potentially consumed by testing, our customers are increasing asking us to help them identify how they can increase test efficiency and drive down their costs. There are a variety of ways to approach this challenge, including the use of test automation tools, alternative testing methodologies or alternative resourcing models and managed services.
As I sat in peak traffic yesterday afternoon, basking in the sun and getting a much needed tan, my mind latched onto a topic I have often pondered over, namely what makes a great BA?
I’ve met Mr Zachman a couple of times now, the man’s a legend of Enterprise Architecture and has undertaken multiple talks and expeditions in the southern hemisphere, lecturing about his very famous framework (http://en.wikipedia.org/wiki/Zachman_Framework). Ever since I first saw the framework, though, I’ve always had a niggling doubt about it. I think after a few of years of contemplation, implementation and some reading on oblique subjects from some good authors I’ve finally twigged it. Zachman’s right, but I think there could be a slightly more useful way to view his framework: In “3D”.
In my recent blog post I explored why architecture as a process was more important than architecture as a deliverable artefact. I talked a little bit about what the defining characteristics of an architectural process are at a holistic level. In this post, I want to take this discussion further and talk about what I appear to me to be the axioms (or “known truths”) of architecture: The things we always come back to, regardless of methodology, framework, personal style or organisational culture. This means that whether you are a proponent of TOGAF, a hard-core Zachman follower, live by a sector framework (e.g. DODAF), are biased by one technology or another, or just making it up as you go along, then these are the “truths” that you consider at the core of your role as an architect.
Have you heard it said that “you need an architecture document here” or “you need an architect on that”? If you have ever worked in or close to the IT industry then this comment, or something like it, is probably something you’ll have come across. If this is you, now ask yourself: When was the last time you heard it said “you need to architect this” with the focus on the process rather than the deliverable? My bet is that it will be less often, potentially never! Architecture is commonly seen as a deliverable, which I think misses the point, and that is the topic of this short blog entry.
For many of our customers, while commercial software packages can handle much of their day-to-day grunt work, unique business processes and requirements still call for custom development for the true value-add applications. But use the term ‘bespoke development’ in front of many CIOs and CFOs and they quail in fear, seeing a future of blown deadlines and escalating costs with no real value delivered. The good news is, it doesn’t have to be that way.
Testing can suck up a significant portion of the budget – in terms of money, time and resources - for any IT project. But if your testing regime isn’t fully lined up with your SDLC, that investment may not produce the high quality, on-time, on-budget results you expect. At Optimation, we work across the full SDLC so we take a holistic view of quality and outcomes. A common mistake we see is organisations over-investing in improvements to their testing practice in isolation from the SDLC, when in fact some of the biggest gains – in terms of reduced waste, improved costs and better business outcomes – may be found in in areas outside of testing’s direct control.