Yesterday Amazon announced immediate availability of Route 53 (their DNS service) tools in AWS Management Console, which is great news for all the AWS users. But it also bad news to services like Interstate53, which I was using to manage DNS records hosted on Amazon, because it immediately renders them irrelevant. It is good time to remind ourselves how addon development is not exactly the best spot for software vendors and how in some cases you can still compete against the platform vendor by having significant value add.

Many junior PMs think that Change Requests (in our company we call them Change Orders) always come to project team from the outer space, whenever the client or other stakeholders want to change something, like increase the scope or tighten the schedule. They think that CRs are there to protect the project team from changes coming outside of the project.

The thing is that CRs are not only about the scope. There are many more controlled project parameters, although the scope is probably the most notorious when it comes to changes. And whenever you need to change any of these parameters you need a Change Request:

• Scope
• Budget
• Schedule
• Specifications
• Quality (if you run projects better than others and really control quality)

When the customer wants to add something to the scope of the project, you need to issue a Change Request to adjust other parameters accordingly. When you need to change schedule, you issue a Change Request to communicate  the change and get approval for it. So Change Requests are not only and not always incoming, they can and should be outgoing to communicate important things, which happen to the project.

Change Requests are meant to protect project stakeholders from silent changes in the project. As much as you want to be informed and be able to react appropriately to the additional work coming your way, the same way project customer wants to be informed and be able to do something on his end, if you decide that final delivery date needs to be moved.

Change Requests are means of communication and no wonder that not doing this part of communication properly can put your project at significant risk. Next time not only wait for CRs to come, but be sure to communicate the changes you initiate to other project stakeholders.

Also check out The Top 9 Reasons Why Projects Fail at The PM Podcast. Communication done right is 80% of successful project.

Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches.

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

• System + external interfaces, then
• Services and components, then
• Add their interfaces, then
• Add interaction (Sequence diagrams) and edge classes, then
• Components' structure and internal interactions, then
• Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.

Have you ever visited a farm? A farm which produces milk, or meat, or even wheat, or corn? If you've been there, I'm sure, you've seen many interesting things all over the place: tools and mechanisms, people and animals. I'm also equally sure, you haven't seen there one thing - variety. Meat farms do not breed cows, pigs, chicken and rabbits. Milk farms do not feature cows together with goats on their premises. Grain farms do not harvest dozens of kind of grain. Instead they specialize in something and they try to stay as uniform as possible with respect to animals they grow, grains they seed and tools they use. Why do they do that? Because variety inevitably means higher costs of operation, but farms can not benefit from variety. For them it makes a lot more sense to have 200 cows of the same kind, than 100 of one and 100 of another since they require different treatment thus rising the cost of support.

On the other hand there are enterprises, which directly benefit from variety - zoos! The more different species you have in the zoo, the more money you can charge for entry tickets, the more visitors you can attract. Yes, operational costs go up as you add more animals - obviously lion requires completely different conditions than pelican, and most likely you will need two different people with different skill sets to look after them. But since you are able to directly sell this variety to customers, it does not undermine your profits.

So, the difference between a farm and a zoo is in their relation to variety: it kills the farm, but propels the zoo.

We see examples of both in our day-to-day lives. We enter farm land, when we rent a car, call a taxi, use corporate computer, eat in McDonald's. We go to zoo, when we shop in the mall, eat in the restaurant, buy a vacation tour.

Look at you business, department, or team and see what you are running - a zoo or a farm. Chances are that you are running a zoo, when you should be running a farm. Run a farm unless you really know how to benefit from variety, which zoo has to offer.

When you work as a Business Analyst, important part you job is to conduct software demos and software reviews with users. User reviews can help a lot to improve quality of your product, but you need to put some effort to ensure efficiency of reviews. Here some some hints on that will help. First and foremost, you go on those review session to hear users' feedback, positive and negative. You want to make users tell you what they like, what functions seem to be overly complex, where performance is not up to par. You do not conduct reviews to impress users, to have them breathlessly admire features you demo. You have to come to those reviews with the only desire to hear your users and make your software even better for them.

Be prepared to hear negative feedback and do not try to defend the approach you took to implement certain feature, when users say they do not like it. If you try to defend people will immediately feel that they are wasting time with you, because you do not care about their feedback and insist on you solution, when they call it wrong. Instead, you want to understand, why they think it is a bad approach, and then propose a solution to that. Audience will appreciate your care.

Make sure that your own feedback and comments were addressed before you show anything to users. Nothing can be more frustrating on the review than hearing something that you already know. At least you need to make sure that review participants are aware that certain areas of the product you review fall out of scope of today's session and they should not pay any significant attention to any gaps there.

Keep audience engaged during the entire review session. When someone makes a couple of comments, he feels like his mission here was accomplished and, as a result, will be less attentive, less willing to interrupt anybody to propose idea. You want to keep everyone in the game, and some tricks from presenter's toolbox can help you with that.

Sounds familiar?

For this weekend we'll get some reading on the topic of requirements in Agile:

• Writing Good User Stories. Nice concept of INVESTing in user stories.
• Latest description of FDD process. Pay attention to step 2 'Building a Features List'. Apart from precise definition of what a feature is, it introduces an interesting idea of time-boxing for features: a feature should not take more than 2 weeks to implement; if that's not the case - break it down.
• Why I still use use cases. Alistair Cockburn on what can be wrong with user stories.
• Writing Complete User Stories. Nice guide on how to address often perceived problems with user stories.

Last weekend we kind of explored the field of software estimation, so it is about time to see, why it is not an easy task. Complexity is what makes estimating hard.

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

-- Jerry Weinberg, Quality Software Management Vol 1, Chapter 9

And here are some more links to explore the topic:

• The Rising Costs of Software Complexity 2001 Dr.Dobb's article.

What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity.

• No Silver Bullet: Essence and Accidents of Software Engineering by Fred Brooks.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

• Recent NASA Study on Flight Software Complexity (via Glen Alleman).
• Code's worst enemy by Steve Yegge. A practical view on software size as main contributor to complexity.
• The Fourth Law of Software Design: Complexity vs. Ease of Maintenance. Another practical report, which discusses how "an average-sized computer program is so complex that no human being could comprehend it all at once in their mind" and what effect it has on software engineering practice.

I love the definition of solution from old good MSF 3.0:

Solution is the coordinated delivery of the elements needed (such as technologies, documentation, training, and support) to successfully respond to a unique customer’s business problem.

There several things in this definition that appeal to me:

• It clearly separates solution, developed with specific customer in mind, from product targeted at market, as also outlined in MSF Process Model.
• Customer's business is in the center of attention. And if the best way to address this problem is not development  of new software, so be it - it can be as simple as re-engineering existing system and providing adequate documentation or training; or instead of throwing development effort at scaling problem, one can just add more hardware capacity. Again, in case this is the best approach.
• There is no place for technology bells and whistles. If a mere VBScript can solve the issue, why waste precious time and resources on ultra-modern super-cool JavaFX (no offense here) development, if it does not add anything valuable for business?
• At last, technology is not a sole focus of solution development: delivery, documentation, training, etc. are equally as important.

Be sure to deliver your customers solutions and not just software pieces. "Software installed" is not a goal here, "problem solved" is.

If your business is in any way supported by IT, vision is an invaluable tool for you to succeed with implementation any enterprise-level project, be it a major enterprise transformation undertaking or deployment of new version of operating system on office computers. [caption id="attachment_288" align="alignright" width="141" caption="Cheshire Cat"][/caption]

Whatever you do, there will always be a question: "What's next?" If you can not answer this question, then how you can be sure that what you are doing is for good? That it advances you towards the goal?

Do you remember this dialog between Alice and Cheshire Cat?

`Cheshire Puss,' [Alice] began, rather timidly, as she did not at all know whether it would like the name: however, it only grinned a little wider. `Come, it's pleased so far,' thought Alice, and she went on. `Would you tell me, please, which way I ought to go from here?' `That depends a good deal on where you want to get to,' said the Cat. `I don't much care where--' said Alice. `Then it doesn't matter which way you go,' said the Cat. `--so long as I get SOMEWHERE,' Alice added as an explanation. `Oh, you're sure to do that,' said the Cat, `if you only walk long enough.'

The same thing with products and projects: if you do not care, what you build, then it, of course, does not matter how you do that. But when you know what is your goal, you can then build strategies, roadmaps and plans to answer the question of "how".

The product roadmap should describe the path from where you are now, to realizing the vision you have spelled out in your product strategy. You do have a product strategy, right? If not, your product roadmap has no real context, and that's a serious problem.

Marty Cagan in Product Roadmaps

Vision enables you to talk about the future and create it in the end of the day.

Vision ties your team together and enables individual contributors to achieve and overachieve.

Vision builds trust between you and your partners and allows you to focus on what you do best.