I'm a complete picture project guy. Let me explain.

Post date: Oct 10, 2014 3:22:46 PM

I personally think for projects it's essential to see the whole picture and understand how things practically work. Unless someone is really taking care of that, the end result will be horrible catastrophe.

This whole post after I did read one post in Finnish software testing blog. They were wondering why testers study testing, why programmers study programming, and project managers study project management etc. Because that's not nearly enough. If you 'just do your job', you're the reason for the major problems which many projects are experiencing.

You'll need to have the complete view of whats being done. And there's no better way to learn it than actually doing it!

What does having a complete picture mean? It means that you'll need to be active and well informed in all the steps required for having a complete view of projects.

1. Sales: As integration & project guy, be very actively involved already in early sales process. No false promises, hands up if task is impossible. Check if the customer is completely clueless and disillusioned or if they have realistic view, scope, schedule and the money. It's very common that they need something, and someone somewhere might know what it really is. Truth is that they don't know, they're clueless. If they can't straight away tell what it is that they're looking for in some reasonable detail. As example, our stock is always big mess, we need a automated stock management system, or something similar. Nope, it won't ever work, it's not the system, it's the process and people, which are most probably reason for the problems and well, it's going to be a painful process. What ever you do, the customer will likely be unhappy anyway. Even if you would stand in the stock counting stuff and trying to track what's coming and going.

2. Requirements: Definition and requirements specification process. You'll need to know what this project is actually about. This is the step which unfortunately doesn't often go deep enough. Often peope think that this is some kind of technical task, but it isn't. It's very important to think about the end users of the project and the processes they'll be actually dealing with. This is the phase where usually the most serious mistakes are done due to saving, and it will ruin everything after this step.

3. Programming: Write the actual code, think about all aspects. I'm sure that you'll find a ton of things, that should be handled, that wasn't mentioned or included in the documentation at the phase 2. Did they specify field content checks

4. Testing: Did you get proper use cases? Probably not. Did you cover everything in step 3? Be creative, try all kinds of ways breaking the system and product. I'm quite sure you'll find plenty. This step can be very easy or very hard, depending from the level we're aiming to.

5. Piloting: install and configure the pilot system. Well, was the installation process nice? Or does it require 200 gimmicks and 50 undocumented tricks, that nobody else than you know about, and even you don't remember all of those? How many previously unknown things pop up at this stage? It can be staggering, if other phases have been going like a breeze. (Nobody cared, everyone just said, that it's great that things are progressing.) Unfortunately, this is the phase, where the customer should do extensive testing, which usually is neglected. They'll do 'just a few tests', and conclude that it's good to go.

6. End user training: This is actually very very important step. Because this is exactly where you'll get swamped by all the things that have been neglected in earlier stages. There's 90 users which say that they'll do this thing using method A. But then there's angry 10 users which say that, no, we don't ever do thing A. We absolutely want to do thing B, we can't accept thing A at all. Great. Why nobody brought up this matter in stage 2? Excellent question. And this is just one example, you can easily get hundreds or thousands of things like this. Unusable UI, fields not missing, bad usability, something doesn't work at all etc.

7. Production launch: If step 6. was done properly, this shouldn't be so bad. But if people were lazy in earlier steps, all those flaws and ambiguity is going to fall on you. This can bring up even more problems than any earlier steps. And now everyones in real hurry to get things fixed. This could mean that code changes are made almost on the fly, without any testing and this can lead to very bad situations, if something isn't working after changes as expected. Often these quick changes also go totally undocumented, because in this case there's simply no time for it.

8. Maintenance stage: If you're active in this stage, you'll find out that all the stuff skipped in previous steps will bug you here. Lack of proper documentation, will bite you. All those kludges, hackish quick'n'dirty prototype quality code, will bite you. All those gimmicks which were needed to get the early pilot to barely work are now also used in production are undocumented and soon forgotten, will bite you hard. That temporary database table you just insert some stuff into and never prune, will bite you. All those totally unusable user interfaces without proper search function, will bite you. 'Rare bugs' which cause some data and relations to get messed up in databases, will bite you. Temporary files you'll litter the file system, will bite you. Locking files and other files which aren't properly transactionally handled, will bite you. Extremely badly written exponentially slowing down code 'which just works', will bite you. Exponentially growing data structures, will bite you. Undocumented features, will bite you.

Conclusion: Unless you're involved in detail in all of these steps, you don't really have a clue what you're doing. And I guess this is pretty much the problem, many larger organizations are having. In every step, they'll 'just do something' and all that junk will end up in stage 8. creating huge endless daily pain. Of course, then there's the question. Because in all earlier steps, it was really important to get it just done as quickly and cheaply as possible. Who's going to pay for fixing this mess? I guess the customer is blaming the project guys for these problems? But where they willing to pay for the job getting done properly? Nope? Great, so who's responsible?

Generic: Even this story was now about software project, I think this basically applies to all kinds of projects. It's also important to notice that software, integration, and other projects should be tightly tied with business processes and goals. If something is only a software project, it will probably end up badly. Or if it's just about building a building, we get it done, but we forgot the residents completely. Maybe it's in such scale, that humans won't even fit into the building. Did anyone mention that we're building the house for humans? Or maybe they were thinking just about the kids?

Security: Because IT system security has been highly visible lately. I'm just going to ask, if this kind of mess which is barely working, has security flaws, who's responsible for those? Nobody really cared, nor is willing to pay for exploring nor fixing those. Actually I often feel that people are much happier when they're not being informed about potential problems. Because in such case, they can always claim that the problem was 'total surprise' and they had no way to foresee it. - Yes they did, but they didn't want to see it. It would mean expensive fixes which done cheaply will cause more bugs and yeah, you'll get the picture.

Failures: I can tell you, that none of the projects with customers who know what they want have ever failed. Of course there has been slight tuning and possibly software bugs, etc totally common stuff. But the projects which fail spectacularly are always projects which are way off from the very beginning. Something is sold to someone who's buying something to solve something that they don't know what it is. Yeah, that's the legendary stuff. We need tomorrow, uuh, system which can do well, our accounting, invoicing and stock keeping and well, uh, we have budgeted 2000€ for it. Unfortunately this is really common scenario, where buyers are simply totally delusional. They're just like a little boy in super car center or something like that.

I know these are questions and topics which many ICT guys aren't willing to discuss about publicly. But it doesn't make the problem go away. I actually think, that talking about these problems is exactly what's required. I'm also reminding that these are completely my personal views and do not represent my former, current or future employers.