Sunday, July 05, 2015

What is a requirement? Well, what kind?

From discussion on linkedin

"What are requirements"

My comment:

A lot of comments already, have not read all of them, but i think the question is too wide. We need some adjectives in front of "requirement". I don't necessarily like all of them myself, but I offer up the ones I hear most: business, process, functional, non-functional , solution, system, even testing. 
I think what most comments here are speaking to is the functional requirement. While precise wording can vary, I hold that the definition must emphasize the concept of "what, not how". I like Jose Santos version, but would shorten it to "A software requirement describes what a software should do but not how to do it, and it satisfies a need." I also like where commentators use the term "future". Certainly a requirement stated now implies a future state where it is met, but it is good to state/think it instead of assuming the implication.

David Wright

prototyping tools are not new, and may already be hanging on your wall.

linkedin conversation on prototyping

Friday, July 03, 2015

So, key man theory and agile.

Later than I thought, but have always wondered about the Product Manager in the agile approaches that feature the role. They are the go-to person for the rest of the team with questions about what is being delivered, yes? What if that person, for any reason, has to leave the project before it completes? What impact does that have? Or am
I asking a rhetorical question?

Friday, April 24, 2015

Key Man Theory, heard of it?

Sometime in the past decades I read about a management idea called the "Key Man Theory". Of course, I can't recall where and when, but it stuck in my brain ever since. In essence, it states that if the success of your business operation or project is heavily dependent on one person, with unique knowledge or skills, you have a huge risk to mitigate. In less sensitive times someone might ask "what happens to us if Dick (or Jane) walk out of the office and get hit by a bus? are we screwed?". The nicer way of saying it now is "what happens if Dick/Jane win the lottery?". Either way, the risk is the same; things could go bad quickly.

This in the same idea as the financial product called key person insurance, but that may not be what you want to fall back on. It is good to avoid poverty if your business fails, but what if you love your business and want to actually save it? In this case the mitigation techniques are to reduce your dependence on the key man (OK, person) by looking to hire similar people, or start some knowledge transfer from Dick and Jane to other people in the organization. Dick/Jane may not be thrilled with this --- being the key person certainly gives leverage when asking for more money or other things --- but you have to do something about this situation; being empathetic and supportive of the key person will help. In the end, when they do leave/retire, they will have felt valued and may have enjoyed passing on their knowledge to the younger folk..

 So, I was drafting some thoughts on another post to come, which refers to the theory.  I thought I would make use of web searches to find some source info or references to use and, to my surprise, my searches found nothing... nada.  So question for everyone: do you remember 'Key Man Theory'? And if so, do you know what happened to it?

Sunday, April 19, 2015

What to do when you see bad methods...

... and can't convince people of it.

I have had this experience a few times, and I have thought long and hard about writing about it.I still don't want to get into details, the old "if you can't say something good..." situation. But the possibility of it happening starts with joining a project already underway and the methods have already been chosen. When I first see something troublesome, I might nicely say something like "this is a bit different, how did come to be used?" The worst answer is "that's how we have always done it", and I really have to shut my mouth before reflexively responding "and how's that been working for ya?" ala Dr Phil.

I won't jump ship because of this (new ships not always passing by), so I make the effort. The real problem comes when you see that using the bad method(s) will make you produce bad or late deliverables. The worst response in this case is "Work harder, Work overtime, etc" because that is what always has happened, so it is seen as the norm for doing projects. Even if what you do eventually produce results in buggy systems and missing functionality, so that the change log balloons, that is also seen as the norm.

My personal problem is that I know it does not have to be this way, so it is tough to continue working to the 'norm'. If you are lucky, some project goes so awry enough that 'lessons learned' are considered; that's when you might have chance to suggest improvements.If not, I start considering my options for moving to a (hopefully) better situation. This could be within the organization if it is big enough, but leaving the org might be what is needed in order to join a better environment.

Anyone want to offer their similar experiences as comments?

Thursday, March 26, 2015

Almost a year...

Almost a year since I posted, my my. Things have changed recently, in a way worth blogging about, so stay tuned...

Thursday, April 10, 2014

Disciplined Agile Manifesto? Good but not what is needed...

Scott Ambler has posted his/DAD's updated Agile Manifesto at

It is indeed an improvement, widening the viewpoint and scope of what is involved in delivery of solutions... and yet, it does not deal with the nature of its objective, the 'consumable solution'. At some point there will be diminishing returns on the ability to deliver the best solution. Ninety percent of the cost related to a solution is incurred after it is delivered. The ability to deal with changing requirements after delivery is more important than before delivery, and yet software is delivered that deals with the moment, and the problem is that changing it after delivery takes too much time and effort.

I have said this before, but what we need more than agile solution delivery is agile solutions; solutions that are designed to accept change without needing to make changes to the solutions themselves. Business process management, Business Rules Management, mix-and-match services. All this out there, but does not get the profile it deserves.

So who wants to help me write an Agile Solution Manifesto? "we prefer configuration over software maintenance..." No, we demand configuration over software maintenance.  Who's with me?

Friday, March 21, 2014

Man, I have been really busy for the last 12 months

Man, I have been really busy for the last 12 months... I worked my last gigs with IAG Consulting, and then went independent to contract at one of the big 5 Canadian banks. It was for 6 months, been renewed, and seems possible a few more extensions will be offered.

I do miss the variety of engagements I had at IAG Consulting over the previous 5 years, and would love to do it again sometime, but a few changes in my needs led to the more traditional contract. That said, it is a great project I am on, to completely revamp how customers are treated when they come into a branch for one product and are helped to look at other complementary products and services for a better overall support of their financial needs. It is a big project , even for this bank, with more BAs in one place and time than I have ever seen before, with the project broken into components that are all being analyzed and designed in parallel.My role is primarily coordination across the components, and as single point of contact to many other stakeholders in the bank. I have been dealing with and learning from people in legal, compliance, privacy, internal controls, anti-money laundering and more.

So that is my past year in a few sentences. I think I will be posting more often over the coming months, probably more about my favourite combination of process, data, rules, services and such.

Cheers for the moment.