UML resources for Visio 2013

imageI am doing some analytical work on a side project these days. Currently, we are in the process of defining the scope of the system, so as the good analyst that I am, I have fired up Visio 2013. Now, I didn’t get the big flashy version of Visio, which means that I don’t have all the stencils I need. In another blog post I wrote about the BPMN 2.0 stencil, but this time around I have to use the UML stencil as I am working on use case diagrams and data models. Luckily the Internet is my best friend, and I managed to track down not only UML stencils but also crow’s feet.

You can grab the UML stencil here and the crow’s feet stencil here. If you are looking for BPMN 2.0 I recommend Orbus. Enjoy.

The seven hard truths according to Popp

Computerworld has a pretty interesting article about the truisms of Hans-Joachim Popp. I am not sure how new these things are, but it is pretty refreshing to see a CIO making these statements. Here are the greatest hits:

  1. Huge projects will fail
  2. A rare and inexplicable error will come back – for sure
  3. Spec will be finalized in the course of system development
  4. Coding (the India part) is of less importance to the project success
  5. Database applications will have performance problems
  6. Professional project managers will make the project look on time until one day before release
  7. The genius super team from the early prototype will fail during rollout.

Rethinking digitization

As wrote earlier, I have been participating in quite a few digitization projects. Usually, the basic premise for the projects has been to emulate a human based process in a digital manner. Or, we have tried to make the shoe fit the foot. One of the things I have noted, is how requirements seem to be incompatible with the how a system works. In my experience, human processes are very agile and easily adaptable to any problems that may arise. As human beings, we are able to improvise very quickly in order to finish a process that has gone awry. IT systems, on the other hand, are very stringent in the manner in which tasks are handled. They can only handle tasks in a given number of ways. This, of course, presents a problem in some cases, as we will not be able to support all human processes in the system.

My suggestion is to reverse the train of thought. Instead of adapting the human process to the system, maybe we should rethink the human process for starters. I am not suggesting that we ignore user requirements at all. I am suggesting that making changes to the human process may indeed yield increased benefit from the system support, since we will be much better equipped to support our users. Most human processes have been cultivated over several years anyway, and it might actually be beneficial to have another look at them, since technology has evolved so much over the years, and maybe able to better support the users in their daily work, if their processes are changed.

What I am looking for here, is an authentic digital process. Not an adapted one. A good example of this is the Windows Phone operating system. The designers did not look to recreate “real life” on a screen, but rather designed a new digital process, which then supports given human tasks. In my opinion, it makes for a much cleaner and more effective process, which hopefully will support human tasks as well as the other scenario.

New methods

I have been in my new job for over a month now, and I a better grasp of the development methodologies. Obviously, I keep comparing the methods to how we did at my old job, since the differences are quite explicit. Whereas before I was submerged in a SCRUM world, I am now working in a team that applies a waterfall model for development.

In all honesty, the beginnings were a little difficult to getting used to. For many years I have been moving at break neck speed with a release every two to three weeks. On top of that there were the ever present bug fixes and panic solutions that characterize that particular organization. This is not meant as a negative critique of anything or anybody since I thoroughly enjoyed most of it. However, the stark contrast between the two methods does merit a comment.

The waterfall approach is without a doubt more cumbersome than the agile approach – that goes without saying. However, I am starting to appreciate the actual analytics that go before actual coding starts. Unlike before, it seems that there is time to identify problems and intricacies a priori as opposed to dealing with them a posteriori. I am pretty excited to see if this actually makes a difference when we start the coding, but I have high hopes that the development phase will be a lot more controlled than what we were able to do when I was apart of an agile team.

One could argue that the comparison in this is invalid, since the agile team made commercial software, and the waterfall team makes software for internal use, which basically changes the premises for the whole reason for developing a piece of software. However, I believe it is pretty valuable to experience both sides of the fence in order to ascertain which parts are useful, and which parts are not.