Nowadays, there are many processes as RUP, Scrum, FDD, XP etc. Each process has its strong and weak points and it advices that users should custom some parts while using, the custom depends on the specific circumstance of project. In any software company, we have the software development process. They can build process by themselves but almost cases, they custom from the well-known process like RUP, Scrum etc. Defining the one process for all kinds of projects seems to be the right solution when company has few projects but the problem will be raised when company get more and more projects.

Why it is a problem when we have common process for all projects in company? The reason is simple: each project has specific characteristics, and they require you must custom our process that adjust its context. However, three problems are raised:

• If company find that the current process can not cover some mistakes in some projects, they will add more rules to process (that means add more works to project members) to prevent this problem in other projects. We can understand this fact as they made the process more 'perfect'. However, such additional rules may not help other projects to fix its problem and project team members do not care its rules but it takes effort of considering, in some cases it takes time for them to do just because the rules define. The consequence of adding more rules is obvious, project effort is increased and company process becomes bigger and bigger. Some projects use a small part of this process, others use another part.
• It takes more time to maintain and study: the more bigger of process, the more time to learn . In addition, it also takes process engineer takes more effort of maintain the consistent of process. Any changes in process take a lot of effort to correct other places.
• Project team members apply process incorrectly: of course, all rules of one process can not apply all to projects. Company allows project can customize process that meet the project goals. However, if project has the right to customize company is not sure that what they think rules are un-needed is correct? Some cases, they remove some rules is the key factors to project success or when they choose another approach but no support from company. I give you a detail example: if there are two projects, one has 40 and other has 10 associates. The first project, client expect you have the formal communication with formal requirements and follow the requirement workflow strictly. The second one, client also require how you develop the application as soon as possible with high quality. With the first project, we can choose to apply the Business Modelling and use cases is the main artifact of managing requirements, it is supposed the company support this approach via templates, guidelines etc. But the second one, project should choose more agile approach of managing requirements such as writing user stories. If the company does not support, team must do by themselves. Of course, user stories may not added to process because in some meanings, user stories and use cases serve for the same purpose.

In manafactoring company, it is clear that we can have one workflow that serve for one product line. Software should not be considered as one product line but it should be divided into many groups that have the similar characteristic. That help company can control the software development process apply for each project strictly, project receive more guidelines for company and the effort to maintain will reduce. Just link to programming language: having a big process for all project is similar with you writing the program using procedure language, if we have one process for each kind of projects it is similar you use OO for programming. Of course, software development process also have inheritance characteristic . Here is the example:

Core Software Process: (the must for all projects in company)

- Requirements, Analysis and Design, Implementation (Code review check list), Testing (Unit test ...)

RUP Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (Business Modelling, Use cases, ...), Analysis and Design (template document...), ...

Scrum Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (User stories ...), Analysis and Design (template document...), ...stand-up meeting ...

The kind of project does not mean about the team size but we can categorize the project base on client's expectation (does they need the formal requirements, test cases ..., high quality product), project's context (lack of client support, domain knowledge is complicated, maintenance on legacy application) etc

Technorati : Project Management Software Development Process

Related posts:

1. Do you need to maintain QC team in your projects – part 2 My have raised the question in part 1 and ask...
2. Preconditions of applying Agile process Probably you already hear Agile process at least one time...
3. Some questions and answers about unit testing I have had an interesting discussion with some project managers...
4. Template projects in software development One the the big challenges in software development is reducing...
5. People is the most valuable asset of organization – it is wrong I have more than 3 years experience of management also...