|
A discussion on Project Management practices, applied to Migration Projects. What has worked for us at ArtinSoft, and what you should avoid when managing a Migration Project
February 2007 - Posts
-
One of the most important metrics that we use to measure the size of a Visual Basic 6.0 code base to be migrated is called Effective Lines of Code. This measurement represents all those lines that will require a certain amount of migration effort and in the case of Visual Basic 6.0 to .NET migrations, it includes the following:
- Visual lines of code: this includes all the code that is automatically generated by the VB6 forms designer. This code belongs to .frm and .ctl files and is not visible to the programmer (if you open a .frm or .ctl file in a text editor such as Notepad, you will see this visual code at the beginning of the file). The reason why we include this as part of the code base to be migrated is that VB6 user interface also represents a manual migration effort, together with VB6 source code.
Naturally, the Effective Lines of Code metric does not include blank or comment lines since they do not imply any migration effort.
|
-
Working days, or business days, are usually said to be 8 hours long. On an average day, you may get to work at 8:30 am and leave by 5:30 pm, having 1 hour for lunch (although this differs from one culture to another, just ask someone from Mexico and you’ll see what I mean!).
Anyway, people usually spend 8 hours at work everyday. However, this doesn’t mean that people are 100% productive in the tasks they’ve been assigned to during those 8 hours. During a normal working day, normal people also check email, make phone calls, talk to their coworkers and do other things that are not necessarily related to the tasks they are working on. As a result, working days are pretty much like soccer games: while a soccer game is said to last 90 minutes, the effective playing time is usually much less than that. Likewise, the effective working time in an 8-hours business day is lower than 8 hours.
The amount of effective hours may vary from an organization to another and from an individual to another. Organizations that keep good project metrics may have a better idea of the average number of effective working hours per day. The important thing to keep in mind here is that even when a team member may be assigned full-time to a task, it cannot be assumed that he or she will devote 8 hours per day to that task. Therefore, it makes sense to think that a task that has an estimated effort of 16 person-hours will take a little more than 2 days to complete with one resource.
|
-
In order to get the most from a time reporting system, several requirements should be met. Historical data that is accumulated in the system will be more accurate and meaningful depending on the way team members report their hours.
Periodicity is very important. Time reports are usually more accurate when team members update their hours daily. If reporting is done weekly, team members will hardly remember how much time they spent on each task at the beginning of the week.
Insist that team members report their hours accurately. Sometimes people don’t work exactly 8 hours a day, so when time reports are “flat” (i.e. 8 hours every day), you may be looking at a symptom of inaccurate reporting.
It is also important to break down the tasks in meaningful sub-tasks, so team members won’t be confused when reporting their hours. If possible, include a description of the tasks; this description will serve as a future reference for post-mortem analysis and historical data retrieval.
Finally, it is not recommendable to use reported hours as a criteria to reward team members. Doing so may introduce more biases in the reports and may cause a negative team response.
|
-
Establishing a time reporting system within an organization can be a very challenging task, but it presents important advantages once the system is in place. Let’s face some hard facts about time reporting:
-
Time reporting is necessary: if you don’t know how much time the team is spending on each task, you’ll hardly know if the original effort estimates for the tasks were correct. Also, time reporting allows you to keep historical data that will be helpful in estimating future projects and optimizing your processes.
-
Time reporting is overhead: of course time reporting is not part of the main tasks that your team members are supposed to execute. Because of this, your time reporting system must be fast, friendly and easy to use. If a team member spends more than five minutes reporting his/her hours, then something’s wrong with the system. Also, if a project manager or team leader has to spend hours chasing team members that haven’t reported their hours on time, then there is definitely a problem.
-
Time reporting is cultural: nobody really likes time reporting when it is first introduced. If there is no plan to communicate the advantages of time reporting to team members, they will probably be reluctant to report their hours in a periodic and timely manner. Basically, you have to sell everybody the idea that time reporting is important and key to the project’s success. Organizations that have succeeded at creating a time reporting culture now possess extensive historical data and knowledge about their own processes.
|
-
Last week, a developer from a company that is evaluating a trial version of the Visual Basic Upgrade Companion sent us an email, asking if they should use the Microsoft Visual Basic 6.0 Upgrade Assessment Tool and the Code Advisor. Perhaps someone else has a similar doubt, so I thought it may be a good idea to share our response here.
First of all, let's remember that we are talking about three separate --and different-- tools:
- Visual Basic Upgrade Companion (VBUC): this is ArtinSoft’s Visual Basic 6.0 to VB.NET/C# migration tool. Basically, you use this tool to convert your VB6 code to .NET.
- Microsoft Visual Basic 6.0 Upgrade Assessment Tool: this tool was written for Microsoft by ArtinSoft, and can be downloaded free of charge from http://www.microsoft.com/downloads/details.aspx?FamilyID=10c491a2-fc67-4509-bc10-60c5c039a272&DisplayLang=en. The purpose of this tool is to generate a detailed report of the characteristics of your VB6 code, giving you an idea of the size and complexity of the code from a migration standpoint. The tool itself does not make any modification of conversion of the source code.
- Code Advisor: this tool is also provided by Microsoft, free of charge, and can be downloaded from http://www.microsoft.com/downloads/details.aspx?familyid=a656371a-b5c0-4d40-b015-0caa02634fae&displaylang=en. The Code Advisor analyzes your VB6 source code and looks for particular migration issues within the code. Each issue is marked with a code comment that suggests how to modify the VB6 code to avoid the problem.
The purposes of the Microsoft Visual Basic 6.0 Upgrade Assessment Tool and the Code Advisor are different, so it is recommended that you use both of them. However, it is important to note that the Code Advisor was designed for users that plan to migrate with the Visual Basic Upgrade Wizard (the conversion tool that comes with Visual Studio .NET), and since VBUC has a greater migration coverage, some of the issues that will be flagged by the Code Advisor will be fixed automatically by VBUC. For a detailed discussion on those issues, please refer to my article “Visual Basic Upgrade Companion vs. Code Advisor”: http://www.artinsoft.com/VB-Upgrade-Companion-vs-CodeAdvisor.aspx
|
-
During a migration project, the issues that your team will face may tend to become repetitive. Because of this, it is important that you have mechanisms that allow team members to share the knowledge that they have earned in the process of migrating the application. This way, you are not likely to have a team member struggling to fix a migration issue that someone else in the team already knows how to solve.
An ideal way of sharing team knowledge during the migration process is the creation of a Project Knowledge Base, where team members can post the solutions that they have applied to previous migration issues. With a good knowledge base, developers will be able to make searches and retrieve information that will help them fix the issues that they are facing, possibly increasing team productivity and reducing costs.
To be effective, your project knowledge base needs to have the following characteristics:
- Easy access: team members should easily retrieve information as well as add new items to the knowledge base.
- Search capability: of course, you don’t want team members navigating the knowledge base for hours to find a solution to a problem.
- Periodic backup: place the knowledge base on a server that is being backed up regularly. In a later project, the information stored may be useful again.
It is common to implement these knowledge bases using a Wiki engine. More information on Wiki can be obtained at http://www.wiki.org/wiki.cgi?WhatIsWiki.
Also, some examples of popular wiki sites are Wikipedia (http://www.wikipedia.org/) and Memory Alpha (http://memory-alpha.org/en/wiki/Portal:Main), this last one is a personal favorite :)
|
-
The other day I heard a joke about project managers told by John Valera, one of the Project Management professors at Costa Rica's Universidad Nacional, so I wanted to share it in this space. I’m not really good at telling jokes, but here it goes…
There was a big project which had three key team members: a software architect, a QA leader and a project manager. These three guys used to go together for a walk after lunch, to relax and talk about the project. One day, they came across an old lamp and when they picked it up, a genie appeared and said:
- “You have awaken me. I’m supposed to grant you three wishes, but since you are three, I will grant a wish to each one of you”.
First, the QA leader said:
- “I wish to flee to some place where I can have all the money that I want, and spend it in whatever I want!” Suddenly, he disappeared and became a rich man in Las Vegas.
Then came the software architect:
- “I wish to flee to some place where I don’t have to worry about anything, and I can have all the fun in the world!” Suddenly, he disappeared and found himself walking in the beautiful beaches of Rio de Janeiro.
At the end, it was the project manager’s turn. With no need for extra thinking, he just said:
- “I wish to have those two guys back at work by 2:00 PM!!!!” :)
|
-
End users are sometimes ignored when planning a migration project. Traditional software development methodologies often lack an appropriate level of involvement from the end user, and this can limit end-user satisfaction with the final product. Before you begin a migration, it is important that you understand the needs of the users of the original application: after all, they are the ones who will use the migrated application in their everyday activities. Be sure to gather the following information on the perception that end users have on the original application:
-
Features that the users dislike: sometimes the users consider that certain features of the original application are not suited to their needs, or should be improved. If this is the case, you will be migrating something that the users don’t like, so you can expect the same disapproval when you finish the migration. Because of this, it’s a good idea to make the necessary improvements after you reach Functional Equivalence on the target platform. On certain cases, rewriting those particular features or modules can be a good option too.
-
Features that the users depend on: in several applications, you will find that there are features the users can’t live without, and even the slightest change of functionality could cause a problem. For example, in a data-entry form that is designed for fast-typing users entering lots of information, something as simple as changing the TabOrder of the form controls could be disastrous.
Of course this list is not exhaustive, so be sure to involve the end users form the beginning of the project and gather enough information from them. Whenever possible, make their needs part of the requirements for the migration or the post-migration phases.
|
|
|
|