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.
Product Managers are among the most important --and influencing stakeholders in a migration project. Actually, they are the “owners” of the application that is being migrated and because of this, they may be reluctant to approve changes to the application.
In many cases, it will not be possible to reach the state of Functional Equivalence in a target platform with 100% the same user interface features as the original application. For example, Tab Controls in Visual Basic 6.0 don’t respond to click events when they are disabled, so the user cannot see the contents of the tab. In Visual Basic .NET, tab controls still respond to click events when they are disabled, so they display their contents in a disabled state. This visual difference is intrinsic to the way the .NET control behaves, and therefore it should be regarded as an expected change after the migration.
Just like the one I mentioned, there may be several changes in the application as part of the migration process. It is very important to make Product Managers aware of these expected changes, and have their approval before the changes are made. Product Managers will have great degree of influence on your migration project, so do your best to keep them on your side!
The developers of a legacy application tend to have an important sense of ownership of the application: probably they’ve spent many months in its design, coding, stabilization and maintenance tasks. Also, they’ve got a lot to say about the future enhancements that should be made to the application, especially taking advantage of the features of the target platform after a migration is done.
In addition to this sense of “fatherhood” over the source code, developers have the best knowledge of the nuts and bolts of the application. Naturally, no one knows the code more than the ones who actually wrote it. Because of this, developers are among the key stakeholders that you must take into account when managing a migration project.
You may find the following tips useful when working with developers as a stakeholder group in migration projects:
-
Most developers will feel very enthusiastic about the migration project. If they are part of the team that executes the migration, they will help keep the team motivated. If they are not in the team, it’s always a good idea to keep them informed of the technical details of the project.
-
Some developers, especially if they are part of the team in charge of the migration, will feel tempted to do some enhancements to the application during the migration project. This may introduce some sort of “feature creep” to the project, possibly increasing the testing and stabilization costs. I guess you don’t want this, so make sure everybody stays focused on the goal of achieving Functional Equivalence first!
-
Developers who are not skillful yet on the target platform will feel rightfully concerned about the migration project. Of course, they need training! Make sure they receive proper training on the target language and technologies before the migration project finishes and they have to continue their maintenance tasks in the new platform.
There are several key questions you need to ask yourself regarding each particular stakeholder that identify in your project. Answering these questions will help you understand these people’s needs and concerns, and will allow you to classify them so you can communicate the right message to each individual stakeholder or group of stakeholders. Some of these questions are:
Note that this list is not exhaustive, as more questions may be necessary depending on your particular situation. Once you have answered these questions, you will be able to classify project stakeholders into several groups, based on their influence, authority, concerns and informative needs. This will allow you to focus on the most important stakeholders (without abandoning the other ones, of course!), and to project the most appropriate messages about the migration project to each stakeholder or group of stakeholders. Keeping important stakeholders on your side will help pave your way to a successful migration project!
In the next posts, we will take a look at some of the typical stakeholders in a migration project.
Stakeholders are people who will somehow be affected –positively or negatively-- by your migration project. In a typical migration, you will be able to identify stakeholders that perceive the project with great enthusiasm: they know that having their applications moved to newer technologies will improve their work, making them more productive as developers and even as end users. On the other hand, some stakeholders will be afraid of the results of the migration project. For example, some developers may fear that their skills will become obsolete in the new software platform, while some managers may worry about the possible disruption that the transition to the new system may generate, and some end users may want to minimize the learning curves that the new version of the application may mean to them.
In an organizational context, you can’t execute a project without taking stakeholders into account. Sooner or later, they will show up in your project to influence it according to their needs or preferences, which in turn may result in helpful support or frustrating disapproval.
The first step that you have to take regarding stakeholders is identifying them. Look around you and identify those people that in some way will be affected by the migration project. Make a list of identified stakeholders, then try to identify their interests and the way in which the project may cause an impact to each one of them.
A key word in stakeholder management is communication. You will be able to deal with the different stakeholders in your project if you learn how to communicate with each one of them, and this is what we will cover in the next few posts.
Migration projects can be quite complex. When you take an application built on a legacy platform and port it to a new language, numerous changes have to me made to achieve the state of Functional Equivalence in the target platform. Because of this, it is recommendable to make Functional Equivalence the most immediate goal of the project, leaving any desired improvements to the application as post-migration tasks. This way, no additional bugs will be introduced due to new code or application changes.
Project leaders should always keep this in mind when directing a migration, since new requirements and improvements will add extra complexity and risk to the migration project. Exceptions to this rule are those improvements that are automatically performed by the migration tool, such as the conversion to Structured Exception Handling and the conversion to ADO.NET that are executed by the Visual Basic Upgrade Companion.
Application improvements can be done gradually once Functional Equivalence has been reached. In the case of migrations to .NET, applications can be improved in a step-by-step process to take advantage of the features provided by the target platform. Some of the improvements that are recommended as post-migration tasks are:
-
Code Refactoring based on the Object Orientation features of .NET.
-
Implementation of Web Services.
-
Changes to the User Interface.
-
Performance Testing and Tuning.