How to design a successful IT project?

I don't want here to discuss the many designing methods, but I write in this page about some "tricks", I applied in the past, which always work.

Method 1

This method I apply many times when the customer is not technical (and not disciplined for software development).
  1. extreme programming 8  I don't choose for the Extreme Programming Method, because it leads to an uncontrolled project (read: chaos)
  2. I get myself a graphical designer and a QC person (who might become the QC manager).
  3. The three of us go to the customer and ask what he wants
  4. The graphical designer makes the screens in a way, that the customer is more then happy (the whole thing with colors and pretty pictures and nice designs)
  5. The QC person/manager is the one, who needs to be involved from the start of the project
  6. If the customer is satisfied, and we have all the pretty pictures, we apply "reversed engineering on the pictures"
  7. We give the customers the design documentation (will probably not read, especially after revisions), and tell him or her how long it will take and how much it will cost and a simple list of instructions for the customer
  8. The QC person/manager makes his documentation and scripts to guarantee that the pretty drawings will represent also the software or product to be developed
  9. I take an experienced GUI programmer and let him or her program the screens (being drawn by the graphical designer) (and this is not a prototype)
  10. Then I get myself programmers and QC people and fill in the blanks (most of the development time is wasted in GUI programming, the harest part of programming a generic program)
This "way of working" works fine with inexperienced customers and development team(s). It's a nice way of making well documented programs in a record time and fully under control. The other good point is that I can 'train' or educate project members.

Method 2

This method I apply many times when the customer is technical oriented and knows exactly what they want. In practice this means that they know the technologies, but they have no idea about managing a team of developers.
  1. Team building. I take the development team and start teaching them development in team and groups effort.
  2. The team will be involved in the creation of the design process, which involves of course requirements, functional and technical design
  3. English: This poster provides a good visual of...I teach the team project management and administration
  4. I take the team members and their families and have at least once a month a social outing (picnicking, I love barbeques). When the spouses get involved, that means that I have much better motivated people in the project. The results are even better then giving anyone a raise of salary!
From this phase, I have one big, happy development family or a close tight team of professionals, containing the following functions:
  1. Software testers
  2. Graphical designer(s)
  3. Team leaders (and in some cases with multiple teams, groups leaders)
  4. Developers (senior and beginning developers)
  5. Coders
  6. The database specialist (mostly is also a developer)
  7. The network specialist
  8. Administrative people. I like control and monitor the project.
And then the fun starts. First of all, I show everyone that I'm in charge by predicting how many everyone is going to produce, how many bugs they will create and how many bugs will be discovered and how many bugs will be corrected. I also show the development team members how good they work and how productive they are and I teach them methods and techniques, which improves their work. For the programmers I will give valuable gifts, like a huge Organization design process programming library with thousands of code snippets, so that they are able to finish their assignments much quicker and with less effort.
  1. The development project really starts. In the project, their are several safety-nets installed, which results in high quality work and a schedule, which will be on time, spot on.
  2. All project members work relaxed and professional and when they don't, I simply educate them. Nobody gets fired, only corrected and all of that with a smile on the face and fun at work
  3. At the end of a normal (project) day, I know what everyone did for work, I have their source code and bug reports and images and databases, etc. I know if the project is behind, ahead or right on time and I know if the productivity is good.
  4. At the end of each project day, I produce a health indicator (a number, representing the health of the project effort) and a productivity percentage.
    1. Those numbers are then for everyone (like customers and general management)
    2. But my personal, professional statistics go much further. I've detailed statistics on each module and program and system
    3. I've detailed statistics about each project member and the sub-groups and know what I can expect
    4. I will know how many bugs a programmer will produce before he or she starts developing and I know how many bugs the QC will catch and how many bugs are hidden.
    5. I'm in control of the project (it's people and the end product) and that makes me feel good.
At the end of the development effort, we are going to have a time of (wild) parties. That's the time of the acceptance tests and they will succeed. Why? The development effort in an organized effort and a simple engineering process. That means we are following simple instructions and that is not too hard, is it? Anyway, the end result is a project, which is delivered on time (mostly earlier) and exactly what the customer expected without fail.

There are many ways of designing and running projects and I've applied many ways and better, I've combined many design and management methods to get to the end product. The above two methods are the most used and have always led to successful projects with excellent products.

No comments:

Post a Comment