Designing a project is a delicate process.
Here we are talking about the customer (who might not be an IT specialist) and the IT (the project organization, which is mainly (IT-) technical). There are many approaches of the design process, all with good and bad sides.
One of the more conventional methods of design is the Waterfall method. This model is a sequential design process, where each part of the project design must be completed, before the next stage can be designed and/or implemented.
This method of design looks logical and through the history of project management, it is the method, which always works. But there are some sat-backs here, and that is time. For example, in a normal waterfall design method, QC and software testing will happen after the development. And that will take a lot of time.
It is possible to adapt another way of QC, where the QC is integrated within the development process, where each piece of code of a completed module is being tested, before it is admitted to the process of integration.
But, in order to let this happen, the development organization must be changed into a model, which for example,l Microsoft is using. They divided the group of developers in small teams of four persons, which one of them is a QC person.
Using this model in Israel is problematic, because senior management is often not (technical) professional, and they become impatient when the project manager is busy with the design. Each day they will ask the project manager why the programmers are not coding.
Prototyping is another design method. It's (originally) a shortcut to show the customer how the program will look like and to give the customer a toy or tool too study it's problem and together with the prototype programmer to come to a good product. Normally, the prototype is not the product, you normally want to have released for sales; it's a model for the project manager to design his project.
In Israel, many companies tend to forget that and the senior management are greedy and cheap and decide to release their prototype as version 1.0. Needless to say, that in all those cases, the product will fail.
In all the years of my experience, I use the prototype method in a different way. The reason to use a prototype is that the customer is not sure what he or she wants, so the project manager supplies a tool for the customer to find out what the customer actually wants. I tent to send a graphical designer and secretary to the customer and let them fight it out until the smallest detail. That works all the time and everyone is more then happy.
To get a customer representative within the project organization is many times a disturbing factor, like what it is being done like in the design method Extreme Programming Methods.
Another method for design is Agile Modeling, which is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Sub-methods are Extreme Programming and Scrum.
The Agile Modeling has some serious setbacks, just like Extreme Programming, and that is that those methods are excellent for small projects of professional team members in a project. And that means in Israel that projects based on those methods are guaranteed to fail.
Planning and feed back loop in Extreme Programming with time frames Extreme Programming and Design is a rather relative young method of designing a project. What is typical, just like the Agile Modeling, the interaction between the client and the project. Also with this method, the simpletons in senior management get their thing, because a project using such method will start to code almost immediate. The idea behind this method is that client changes are more then welcome and almost immediately implemented during the project.
That is fine, but in practice is that with complicated projects it means that the project will fail because of the enormous load of defects. That is a strange statement, because the Extreme Programming and Design model has the important task build within the methodology for (automated) testing for each module in the project. So, theoretically, the software has not many defects, but in practice there will be many defects, but of the worst kind, namely defects in the design.
The Extreme Programming and Design methodology also does not know many official design documentations and all project planning is based on 'hot air'. If the project manager is calculating series of tasks for a certain fixed duration, he does not know if the customer in that stage will demand changes! And in this way the project will be delayed and crosses the due dates with thousands of percentages.
In those cases, I always tell the senior management that a project like this is not a fixed time-based projects, but the senior management never understand and only a few accept it. They always like to know when is it ready? And they don't understand that if they demand changes during a project, the price of that is high.
After more then 10 years of suffering such scenario's, I found a golden method. I started to use in the project design the term Resource per Dollar, megabyte of code/Dollar. For example, I calculate the price of each kilobytes per dollar or each dollar per kilobyte, like 1Mb=$5.67 (which means here that each kilobyte a programmer is coding, the price is $5.67. When the senior management or customer wants to change something again, the result is then a higher price (for example 1Mb=$7.75). If that is not clear, I tell them straight out the cost in dollars instead of 'small' details like five more weeks of development.
I always use the Vee-model in project- and product design, because it means first design and then products operation at the end. This principle of this method means the most complex item on top and least complex item on bottom. And of course, the Vee-model is then integrated in all other different design modeling I use in all kinds of projects.
As a designer, or project manager, I never use a certain designing method in the sake of a good method in my opinion. This depends totally on many other factors. One of the factors is the professionalism of the customer or the senior management. If they are technical illiterate, I use creative ways to build the requirements, like prototyping or sending them a graphical designer and secretary and done with it. The project organization will then be chosen based on the method of design. When we are talking about a professional organization, then I mostly go with the technical methodologies, but this will depend on the technical expertise of the technical people.
Here we are talking about the customer (who might not be an IT specialist) and the IT (the project organization, which is mainly (IT-) technical). There are many approaches of the design process, all with good and bad sides.
One of the more conventional methods of design is the Waterfall method. This model is a sequential design process, where each part of the project design must be completed, before the next stage can be designed and/or implemented.
This method of design looks logical and through the history of project management, it is the method, which always works. But there are some sat-backs here, and that is time. For example, in a normal waterfall design method, QC and software testing will happen after the development. And that will take a lot of time.
It is possible to adapt another way of QC, where the QC is integrated within the development process, where each piece of code of a completed module is being tested, before it is admitted to the process of integration.
But, in order to let this happen, the development organization must be changed into a model, which for example,l Microsoft is using. They divided the group of developers in small teams of four persons, which one of them is a QC person.
Using this model in Israel is problematic, because senior management is often not (technical) professional, and they become impatient when the project manager is busy with the design. Each day they will ask the project manager why the programmers are not coding.
Prototyping is another design method. It's (originally) a shortcut to show the customer how the program will look like and to give the customer a toy or tool too study it's problem and together with the prototype programmer to come to a good product. Normally, the prototype is not the product, you normally want to have released for sales; it's a model for the project manager to design his project.
In Israel, many companies tend to forget that and the senior management are greedy and cheap and decide to release their prototype as version 1.0. Needless to say, that in all those cases, the product will fail.
In all the years of my experience, I use the prototype method in a different way. The reason to use a prototype is that the customer is not sure what he or she wants, so the project manager supplies a tool for the customer to find out what the customer actually wants. I tent to send a graphical designer and secretary to the customer and let them fight it out until the smallest detail. That works all the time and everyone is more then happy.
To get a customer representative within the project organization is many times a disturbing factor, like what it is being done like in the design method Extreme Programming Methods.
Another method for design is Agile Modeling, which is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Sub-methods are Extreme Programming and Scrum.
Planning and feed back loop in Extreme Programming with time frames Extreme Programming and Design is a rather relative young method of designing a project. What is typical, just like the Agile Modeling, the interaction between the client and the project. Also with this method, the simpletons in senior management get their thing, because a project using such method will start to code almost immediate. The idea behind this method is that client changes are more then welcome and almost immediately implemented during the project.
That is fine, but in practice is that with complicated projects it means that the project will fail because of the enormous load of defects. That is a strange statement, because the Extreme Programming and Design model has the important task build within the methodology for (automated) testing for each module in the project. So, theoretically, the software has not many defects, but in practice there will be many defects, but of the worst kind, namely defects in the design.
The Extreme Programming and Design methodology also does not know many official design documentations and all project planning is based on 'hot air'. If the project manager is calculating series of tasks for a certain fixed duration, he does not know if the customer in that stage will demand changes! And in this way the project will be delayed and crosses the due dates with thousands of percentages.
In those cases, I always tell the senior management that a project like this is not a fixed time-based projects, but the senior management never understand and only a few accept it. They always like to know when is it ready? And they don't understand that if they demand changes during a project, the price of that is high.
After more then 10 years of suffering such scenario's, I found a golden method. I started to use in the project design the term Resource per Dollar, megabyte of code/Dollar. For example, I calculate the price of each kilobytes per dollar or each dollar per kilobyte, like 1Mb=$5.67 (which means here that each kilobyte a programmer is coding, the price is $5.67. When the senior management or customer wants to change something again, the result is then a higher price (for example 1Mb=$7.75). If that is not clear, I tell them straight out the cost in dollars instead of 'small' details like five more weeks of development.
I always use the Vee-model in project- and product design, because it means first design and then products operation at the end. This principle of this method means the most complex item on top and least complex item on bottom. And of course, the Vee-model is then integrated in all other different design modeling I use in all kinds of projects.
As a designer, or project manager, I never use a certain designing method in the sake of a good method in my opinion. This depends totally on many other factors. One of the factors is the professionalism of the customer or the senior management. If they are technical illiterate, I use creative ways to build the requirements, like prototyping or sending them a graphical designer and secretary and done with it. The project organization will then be chosen based on the method of design. When we are talking about a professional organization, then I mostly go with the technical methodologies, but this will depend on the technical expertise of the technical people.
Related articles
- The Waterfall Dentist Anti-Pattern (sanderhoogendoorn.com)
- Design Your How: Dealing With Client Pushback (theindustry.cc)
- SolidSmack: Selling the Story: The Design Process as a Marketing Tool (solidsmack.com)
- Another Link In The Chain: Connecting Project Management to the Supply Chain (kinaxis.com)
- Agile XP Meets Critical Chain - Part 1: Getting Faster Delivery (spin.atomicobject.com)
- Asshole Driven Development (scottberkun.com)
- Thinking About Waterfall, Extreme Programming And The Agile Enterprise (pr.typepad.com)
- From Traditional to Iterative to Agile to Disciplined Agile (ibm.com)
- Comparing the Disciplined Agile Delivery (DAD) framework to RUP (ibm.com)
- DIY Process (cognition.happycog.com)
No comments:
Post a Comment