November 2006 - Posts

• Key Stakeholders: Developers

  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. Posted Nov 28 2006, 08:14 PM by jpena with no comments

• Identifying Key Stakeholders, Part II

  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: How will this person (or group) be affected by the migration project? How will their work be changed? What is the level of influence that this person has in the project? Are they supporting the project, threatening it or just awaiting its results? What is the level of authority that this person has in the organization?  Is he or she a decision maker? What kind of information does this person expect about the project? Do they need progress, financial or technical reports? What kind of language should be used with this person? Technical, administrative or just simple language? 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. Posted Nov 25 2006, 03:25 AM by jpena with no comments

• Identifying Key Stakeholders, Part I

  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. Posted Nov 18 2006, 01:08 AM by jpena with no comments

• Functional Equivalence first, Improvements later!

  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. Posted Nov 17 2006, 06:55 PM by jpena with no comments

• A Migration-related PM blog

  After more than 3 years of managing migration projects here in ArtinSoft, I have decided to start this Project Management blog.  In this blog, I would like to share some of the experiences and knowledge that we have accumulated during this time on how to deal with the complex task of leading an application migration project.  I hope that the information posted here can be useful to Project Managers and Development Leaders that are in charge of migration projects.  Please stay tuned! Posted Nov 04 2006, 02:20 AM by jpena with no comments