|
|
Blog by Richard Zaat, Senior Consultant, RUP Coach and MRMUC trainer at Info Support
-
This year I attended the IBM Rational Software Development Conference (RSDC) 2008 in Orlando, Florida. One can really see what is going on inside IBM Rational at the moment, and where the Rational world is turning to. There were 300+ sessions, divided into 14 (+ one executive summit) tracks. What I have taken back from this conference is: - Teamwork (especially with the Jazz platform, in which IBM already invested $250 million)
- Process is dead, long live practices (as first advocated by Ivar Jacobson, and nowadays followed by IBM). This simply has to get its reflection within the RMC product.
- Agile, agile and again agile. All three meaning different levels of agility....
- Toyota and its quality are superb and often referred to
There were a lot of interesting speakers: Scott Ambler, Per Kroll, Ivar Jacobson, Grady Booch, Erich Gamma, Ian Spence, Kurt Bittner.... Slides In 2007 IBM send the attendees a CD containing all presentation material. Too bad they are not going to do so this year. Every attendee has received a username / password which can be used to access the presentations via the web. This means you have no control whether the interesting presentation will still be there tomorrow. To solve this, I have come up with the following solution: Unzip the file attached to this blog Use Firefox, and install the plugin called 'Download them all'. This plugin allows you to download all referenced .zip files (amongst others) on a single webpage. Saves a lot of 'right click | Save as'. Go to the IBM RSDC 2008 website and download all the presentations from all the tracks. Unzip the presentations in the presentations directory (created by the zip file in step 1) Start the website by using either the 'index.html' or the 'agenda_by_speaker.html'.
Note: The aim was not to deliver a complete working website, but just one in which it was easier to identify the content of the presentations and allowing a quick link to the real presentation (and not another zip file). Enjoy!
|
-
After I installed the K-Lite Codec pack, I sometimes get this Avi Chunk Viewer window at the most annoying times possible. It seems this is caused by a codec called Avi splitter. It pops up when there is an avi found with an incomplete footer. To remove the Avi Chunk Viewer, do the following: 1. Start the K-Lite Codec Tweak Tool, located in the K-Lite\Configuration start-menu. 2. Go to the Disable part, and select Avi Splitter. That's it. Although you might have to reboot your computer.
|
-
When browsing the internet, I stumbled upon this website with loads of information about requirements: http://www.requirementsnetwork.com. It contains very useful information, which is presented via: - Forums
- Blogs
- Articles
- Webcasts
- Tools
Worth registering (free) and keep as a favorite.
|
-
If you are looking for a list of Requirement Tooling, or more
information about Analysis, Requirements, the Requirements Management
Template, definitions of models, take a look at the following website:
http://www.jiludwig.com/
It is a rich archive of requirements related information.
|
-
I've noticed many times that projectmanagers find themselves the keepers of the deadline. Everything has to go to reach the golden target, the deadline.
And mind you, there is nothing wrong with trying to get things done before the deadline. What is wrong however, is the ownership of the deadline.
To me, the projectmanager does not have a deadline. The projectmanager will do its best to achieve the work in time, but the real owner is the customer.
And that is a huge difference! Why? Keep on reading...
The reason for a deadline There are usually a few reasons for having deadlines: The customer usually will suffer if the deadline is not met. But, it is also up to the customer to move the deadline! Therefore, in my opinion, the customer is the owner of the deadline.
Projectmanager and deadline How come many projectmanagers feel they own the deadline? I mean, if the solution is not in production at a certain moment in time, it will not influence the projectmanager directly (of course, corrective measures from the business will have their influence, but that is a business penalty, and has nothing to do with the solution).
Somehow projectmanagers step into the shoes of the customer when it comes to deadlines. I think it is mostly because the customer does not show any interest in the IT solution, and puts a lot of pressure on the projectmanager. Sometimes fear for the customer, or the penalty plays a role as well.
What to do?
First, the projectmanager must involve the customer, and make the following clear: 1) The customer is the owner of the deadline
By having the customer as the owner of the deadline, it is up to the customer to decide what to do and leave, help prioritize, and spend additional money if required, or even move the deadline a bit. After all, if the solution is not delivered in time, or with the wrong requirements, or quality level, it is the customer that will suffer the most.
2) The projectmanager will do its best to achieve the deadline (hey, this is really being service minded! -> try to help, but stay realistic)
If the projectmanager takes on the role of a service-provider, he will assist the customer in making the important decisions. The projectmanager will make clear what is possible within the current time / budget / resource, and what is required. But the decision stays with the customer. If you have too much work and too little resources / time / budget, make it visible to the customer, and have the customer decide. That is service delivery!
Once all this is clear, make an appointment to speak the customer at least once every two weeks. Discuss the progress of the team, the problems, and the issues and risks. Prioritize together with the customer. Make the customer feel important for the project. Really give them the role of the owner of the deadline.
What if the customer does not want to be the owner?
You do not really want this. It means that the customer is not involved, which to me means that the deadline is fake. If it is really important, the customer would love to be involved. But anyway, if this is the case, make sure that all your decisions are communicated towards the customer. Play it open, and tell the customer what requirements you will skip, and how you will prioritize your work and prioritize the requirements. Keep mentioning that if you do not hear anything, you will assume that your decision has been agreed upon (remember, this is business, with a deadline, you are in a rush, and there is no time to wait). Eventually, the customer probably will become involved, without even knowing it. Especially if you take some foolish decisions!
Conclusion As a projectmanager, do not act like you are the owner of the deadline. The customer owns the deadline, you will only do your best to achieve it. Some things are impossible, and it is your task to show that to the customer (e.g. you cannot give birth to a baby with 9 women in just one month).
|
-
I have found an interesting website http://www.clarrus.com/resources.htm which contains useful information about:
- Project Management Tips
- QA, Test, CM Tips
- Analysis, Design Tips
- Business Tips
- People Tips
- Process Tips
- Recommended Books
- Articles
There is loads of information present, which will help to develop new approaches / ideas.
|
-
RUP itself has many different roles (Project manager, System Analyst, Software Architect, Technical Writer). So what's the use of having so many roles, while you know that you surely will not easily have enough people in your team to have a 1-1 relation. Most teams I come across are 6-15 people. According to the Standish Group it is best to have a project of 4 people, which may take at most 4 months. Now what to do with all the roles defined in RUP when having a small team?
By assigning a role to a person, you are not just saying 'you have some importance in this project'. No, you are also handing out responsibility. Because a role is responsible for artifact(s). And if you are using a Development Case, in which you have stated the artifacts your project will deliver, then you can use RUP to verify which roles to hand out. Say for instance that you want to have User Support Material. Just use RUP to look up the role assigned to the artifact. Looks like you should assign the Technical Writer role to one of your team members. And with it, s/he will also become responsible for the Manual Styleguide (if you will create one, according to your Development Case).
Make sure that all the roles (related to the artifacts from the Development Case) are divided amongst the team members. Now you can be sure that there is always a team member that should feel responsible for any artifact that is mentioned in the Development case.
It is very easy and straightforward, and avoids people saying: I wasn't supposed to do that, but I also do not know who was! I though the Project Manager had things covered.
I have seen projects where not all roles were assigned. The good thing was that all team members where team players, and they decided to perform the work (not even knowing which role they were missing) that was left to do. At the end, during the evaluation of the project, it became clear that the role of Deployment Manager had not been assigned to anyone.
Besides using your Development Case, you could also take a different approach. Sum up all the roles within RUP, and see if you want to have this role in your project, and who should have it. If you do not have a certain RUP role assigned to a person, check the related artifacts, and verify that you really do not want to deliver those artifacts. Or verify that you have made a change based on RUP, and that another role is now responsible for the artifact. For example, sometimes the System Analyst also creates the Analysis Model.
Conclusion: Use the roles to assign responsibilities about artifacts, it ensures that the team members know what is expected from them, and what it is they need to deliver.
|
-
RUP itself has some clear milestones, for each phase (Inception, Elaboration, Construction, Transition). Trouble is that you usually can't just say: I've saved the last document of Inception, now we are ready for Elaboration. Reaching a milestone is something which doesn't happen all of the sudden. And this means that closing out a phase is not always clear. Have we really "All risks have been identified and a mitigation strategy exists for each." covered that part? How do you know? Have you really identified all the risks when you are confident you have taken all required actions to identify them? You will always have a feeling that it is possible that you missed something... and this usually makes closing out a phase difficult. At the end of Inception usually some of the projectmembers are already doing some elaboration work. So when can you continue to the next phase? As soon as someone starts taking up activities from the next phase? Or when all work from the current phase is completed? No. Closing out a phase is not binary (yes or no). It is a feeling that the milestone has been reached. This will probably leave some doubt whether the decision to go to the next phase was right or not. And that is why this decision should not only be taken by the projectmanager, but by everyone involved. I use phase assessments and evaluations. The evaluation is for the improvement of the team itself. The assessment is to see whether everyone agrees on the fact that the milestone has been reached. Talk about the indifferences. Write down the milestones, and ask each stakeholder if the milestone has been reached (let them give a rating of 1-5). If a milestone is 4 or higher, there is no need to discuss it. When the milestone reaches an average of 3, you have a discussion at hand. If it is below 3, you cannot continue to the next phase. The rating helps to change the gut feeling into something which can be discussed. So, discuss the milestone with the whole team (or at least the most important players within your team) and make a decision together. Sometimes our outcome is that we have reached the milestone, but only once a specific list of actions has been taken. In this case the assessment helps to set the focus for the short time period. Conclusion Decide together if you have reached the milestone. If not, make a list of actions required to reach the milestone anyway.
|
-
While surfing the internet, looking for information about project measurement and iteration review criteria, I found the following website. I can strongly recommend this site for Process Engineers, as it contains (and will contain) many interesting articles. The following introduction is copied from the website: The primary goal is to offer a place for Software Process Engineers (Architects of the development process) to obtain and offer ideas about the role of software Process Engineering. What works and what doesn't. Its also to share the software development process and how to apply it to teams in general. UML and modeling are a large part of this sites interest, but we try and cover all the disciplines, wherever we find useful information.
The site's aim is also to form a central collection point of relevant information about this emergent role of Process Engineering in teams doing software development. A place where useful material can be found by all people of all disciplines, both practical and theoretical, where newcomers to process can get help to get started or more experienced Process Engineers can benefit from others experience. A central junction to all things software process and software process related.
|
-
Most information shown, created by the Standish Group, about the core elements of project success / failure base themselves on the information dating from 1994.
The Standish Group has renewed their Chaos top 10, as can be downloaded here.
In short it contains the following:
1. CHAOS TOP 10
- Executive Support
- User Involvement
- Experienced Project Manager
- Clear Business Objectives
- Minimized Scope (instead of small iterations)
- Standard Software Struture
- Firm Basic Requirements
- Formal Methodology
- Reliable Estimates
- Other
2. The kind of skills that are required for each role, to tackle the top 10
3. Ingredients for a succesful project:
- Reducing Requirements to the bare minimum
- Constant communication systems
- Standard infrastructure
- Good stakeholders
- Iterative development process
- Project management tooling
- Adherence to key roles
|
-
FMI Solutions has published an on-line 'training' on how to integratie RUP and PRINCE2. It will help your organization to find its own way.
View the training here.
|
-
Many organizations use PRINCE2 at their project management level. Introducing RUP means introducing an overlay in process description.
At the website of IBM, the following interesting (and practical) whitepaper became available.
Introducing the loose coupling allows for the current organization to keep working the way it used to be (that is, at management level) and still create a process at the Software Development Level that will improve the success rate of IT Projects.
You will find the article here.
|
-
-
Welcome to my first blog and post.
I've been in the IT for almost a decade now, not counting the years studying IT. My interests are both on the IT and human side. Many times the purpose of the system is forgotten: someone needs something which works for them!
During my career I have been a developer, designer, system analyst and currently working as a RUP process engineer. As Harry Nieboer is leaving the company, I will continue some of his work. The parts I will take over are the Engineering layer of the Info Support “Ontwikkelstraat” (software factory) called Endeavour, as well as the training RMUC and RUPF.
To me this is a great challenge, and I wish Harry the best.
|
|
|
|