This is a true story. The company name
has been changed.
The data conversion
Acme Corporation was a retailer based
in Canada and in France. They were replacing the separate Canadian and French systems
with one common system, including financial as well as sales and distribution
modules.
Early in the project, a software
developer in France was assigned to design and create data conversion programs
to load data from the two old systems into the new system. The developer was familiar
with the French legacy system but not familiar with the Canadian system or the
new system. The developer’s experience with the French legacy system provided
her with some knowledge of the business and its system requirements. However,
she had always worked for a supervisor or project manager, and did not have any
experience at managing work.
Several members of the project team expressed
their concerns to the project manager. Surely the one developer would not have
time to plan and develop all of the programs needed to convert data from both
legacy systems. The project manager was not worried, as the developer had
always got assigned tasks done in the past.
After several weeks, there was no
visible action from the developer, and the project manager was still
unconcerned, so a couple of team leads on the project decided to try and move
things along. The Purchasing/Accounts Payable team lead called a meeting to
discuss data conversion requirements for vendor master and purchase orders. The
Sales/Accounts Receivable team lead called a meeting to discuss conversion
requirements for sales orders, pricing, and customer master.
The developer took some notes at these
meetings and said she was going to start coding extracts from the French legacy
system. She did not provide any confirmation to the team members about what
would be delivered. In addition, she spent no time working on extraction of
data from the Canadian system.
The team leads continued to press the
project manager for answers about how the data conversion was going to get done
with only one resource. After a few more weeks, the project manager assigned a
second developer to write the data conversion programs for the Canadian data.
The two developers had no shared design to ensure that the separate work done
for the two legacy systems would have similar results in the new system.
The team leads kept voicing their concerns
to the project manager, that the data conversion was not well planned, that
there might not be consistency in the data from the two countries and that the programs
might not be done on time. The project manager saw no need for the developers
to stop their work to do some planning.
At the project status meetings, it became
clear that the team leads and the developers had different ideas about what was
to be delivered. As a result, additional meetings were held and the programmers
took notes on additional files to be converted.
When data was loaded into the new
system for testing, the team members were shocked at how many fields were
missing or incorrect. The team leads again approached the project manager with
their concerns about the data conversion and whether it would be on time and of
acceptable quality.
The project manager still thought it
didn’t make sense to stop and coordinate efforts between the two countries or
to create a schedule at this late date. He decided that the developers
were too busy working to take time out for planning.
The project manager starts to worry
When the go-live date was less than a
month away, the rest of the system implementation was going well, but the data
conversion work was significantly behind, the project manager got worried. Conveniently
for the project manager, he was directed by the steering committee to delay the
project go-live date by three months. Acme was acquiring another company and
the system implementation would be delayed for a few months to allow Acme to
focus on store amalgamations and training the new employees on Acme’s way of
selling products. The project manager was very relieved. He did not have to be
the one to defer the go-live date due to a late and inadequate data conversion.
Conclusion
The project manager made an invalid
assumption right from the start and kept to it even despite evidence that
proved him wrong. He thought that since the French developer had always got the
job done when given assigned tasks that she would also be able to deliver when she
needed to define, plan, and manage the work as well. Project management was not
a skill the developer had learned and so the assumption was unfair.
In addition, although the project
manager monitored the progress of the rest of the project very carefully, he
didn’t pay much attention to the scope, resourcing and delivery of the data
conversion. He assumed that data conversion was a small and easy task compared
to the rest of the project. If he had ensured that scope was defined and a schedule
was developed at the start, he would have realized the extent of the work to be
done. Even some preliminary discussions with other project managers would have
given him better insight into the likely challenges of the data conversion
work. Except for the company’s timely
acquisition of a competitor, the project manager would have faced an
embarrassing and costly project delay, due to his reluctance to define and plan
the data conversion.
Unfortunately, both developers were
uncomfortable about asking for help. They would have been wise to insist to the
project manager that they needed help with the planning and coordination of the
two countries’ requirements.
Copyright
2015 Debbie Gallagher
