Following a defined process, such as an instance of the RUP, is not an easy way for a project manager to abdicate responsibilities and forgo common sense. The job does not consist in blindly developing any and all artifacts described in the RUP, hoping that the right thing will happen. The tasks do not consist of allocating all activities of the RUP to the team members and then saying, "Oh, I simply followed the RUP! I do not understand why we failed." Recall that you should select out of the RUP the right set of artifacts, the right methods and techniques, and adapt them to your context. You must understand the project and the product deeply, and work with the architect, the analysts, the designers, and the testers. You will be judged on concrete results, not on the means you have put in place. Your role is to steer and continuously adapt the process as the project unfolds, deciding which artifacts and which activities are bringing concrete results. To do this, you must get deeply involved in the project life, from a technical standpoint, to understand rapidly the key decisions to be made, to seize opportunities to get certain results faster, to manage the scope of the project, to "size" the process. This is done efficiently only in a collaborative manner, not by imposing a rigid bureaucracy, setting up a distance between project management and the rest of the team. Remember also that all the management activities not described in the RUP are also very important. You are not managing machines; you are not managing behaviors; you are managing people . Just running around and telling them what to do and pointing at the RUP won't do. You are setting goals and establishing a software development culture, a culture of collaboration and trust. And this is done through a high and constant level of communication. So, to summarize:
|