Having recently attended the two-day ‘Use Cases to User Stories’ workshop with Dr Alistair Cockburn, I thought it would be great to share some of my insights and learnings with you.
What makes two people who are madly passionate about Business Analysis want to bring a tropical storm down on their Business Analysis Practice by introducing design and design thinking?
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.