A few points of early phases for a very-large project

"Very-large" means it covers the whole company that has over 5 billion revenue (I choose 5 billion, because companies over this size usually have some characteristics of being "big").

1. When you have a very large project, you have to think about outsourcing as the first option.

2. Regardless outsourcing or not, discovery and documentation of business workflows or/and business use cases must be the major activities for a long time (3 months to half a year), without doing anything else – the first round of this is a strict waterfall, and it does not need to be very technical.

However, in the beginning, it is very important that business people have help from IT so that they know how to do business workflow and business use case analysis. It is absolutely not that case that business people “just know” how to do the analysis.

3. If outsourcing, then, you need to evaluate venders’ architecture; if not outsourcing, you need to design and simultaneously prototype your own architecture.

Note that it is necessary to evaluate venders’ architecture. Just evaluating itemized business use cases does not cut it. Yes, inductive thinking is still important; but strong deductive thinking is equally important at this phase. This means at this phase, you need very-technical people in the team even you prepare to outsource it; otherwise, prepare for disasters that will happen when it is too late.

My key point here is phase 3. In almost every very-large project I have been through (more than 7, so, it has some statistical meaning), this phase is the most difficult one, because it requires a lot of power transferring from business oriented non-technical team to technical people. It requires a lot of trust: especially considering the context that when you need a very-large project, it almost always means that the current system is not working anymore. So, that trust is really a leap of faith.

ITIL -- we have a winner for a higher level process

Recently, I looked into ITIL. For more info, this is a good place to start: http://en.wikipedia.org/wiki/ITIL#Certification

Before using ITIL, I have been using XP/Agile, RUP/UP, CMM, and ISO 9000. Believe it or not, those things are not high-level enough. I remember that I have to work with many people to help to create a higher level process to incorporate best practices for doing both support and development.

ITIL is a good fit for the higher level process.

As always, deep in my heart, I advocate we maintain a healthy dose of cynical attitude to any processes. However, it is good to have a reference when you are in the activities in helping to create a high level process. It introduce some objectivity: not everything is about politics after all.

How to introduce a good process and how to de-politicize process

How to introduce a good process and how to de-politicize process

-------------------
I have not written any blog for a while, because I need a break after finishing ERAD (Enterprise Rapid Application Development, see my previous blogs), as a concrete example of “8 Core Programming Techniques”.

For a moment, it is almost perfect. However, it does not last long …

The setup of “8 Core Programming Techniques” is to ensure that it is not too high in the “architecture” and “process”, and it is not too low and buried in “coding” and “design pattern level designing”. The reason for that is that it then can “sense” all those things in a right amount of mix. In other words, it is set up in such a way so that it is sensitive to all levels and aspects of programming. As a result, I cannot stop blogging for too long, because here I can sense another interesting problem: how to introduce a good process.
---------------------

Immediately – if you read my previous blogs – you may say, you are an anti-process guy, why in the world do you care introducing a good process …

So, I have to say that, I am a pro-“anti-process-process” guy, or, you can say, I am a pro-TDD-process guy. However, because there are so many interpretations of TDD, so, let’s put that aside for a while, and let’s just say, I am a pro-good-process guy.

OK, so much for the word game. Let’s take a look of the reality.

Introducing a good process is not easy. A lot of times -- too many times -- process is politics. Management almost always tries to use process as an organizational tool. As a result, it is always a long and most of time painful process.

Note that after going through many of them, I totally understand that process is indeed close to politics. It is only “natural” that management (and actually a lot of developers or other “doers”) uses it as a tool for politics. I am not naïve; on the opposite, if you read my blogs, you know that I am very cynical about processes, any process, including TDD ones.

However, if you are really pro-process, you have to agree that process is a serious engineering domain. I believe that to introduce a good process and to de-politicize process are the two sides of the same coin. Yes, in other words, the primary obstacle of introducing a good process is to politicize the process.

Let’s make it even more confusing: actually, good politics always give a common and relatively stable goal for everybody, so, it is not politics; it is about bad or good politics … -- OK, let’s do not make it so confusing, let’s assume “politics” is a bad word in engineering domain …

Again, note that there is a lot of human psychology in process. So, saying that process is in engineering domain does not mean it is all about machine. It is human-psychology engineering also. However, it is not politics … I know, it is confusing, and that is exactly the reason that we are so easily got confused about this.

Before I get confused myself, before it is too late, let me keep it simple: there are two approaches:

A. Introduce it by hiring a well-known consulting company to give a 2-week training courses for everybody, managers and developers and other “doers”, the same time, the same classroom;

B. Announce that we begin to use process, then, baby steps, try one thing, and if it seems good, then bless it as part of the process.

Based on my long time experiences, although approach B sounds benign and innocuously common sense, it is actually the source of all problems.

You may ask: what process you are talking about: TDD or RUP or others? To be frank, it does not matter, as long as it is “good” -- they are all similar: they are all about the art of the waterfall with iterations. The key is that “software development process” looks like common sense and is similar to management basics; however, without proper systematic training, it is almost inevitable to mess it up big time. Everybody can say he/she knows “process” until making a big mess. Software process is not just like other management basics; before you have real experiences, you got to get it via systematic training.

Let’s stop here, and think about it for a while ;-)