Category Archives: Best Practices

Tools, techniques, and other additions to the knowledge base of the practicing IT project manager.

Managing Change Orders

Posted on by
Reply

We recently processed a change order to one of my projects.  Like all of our projects, it’s a joint effort with the client – each organization has responsibility for certain deliverables.  In this case, the original statement of work had the client developing all eleven of the integrations to other systems.  These integrations are essentially files of change transactions, passed from the system of record to a destination; nine outbound and two inbound.  This approach was identified as a risk to schedule up front, and sure enough, once we got started, they realized they couldn’t deliver in time.  So they asked us to take over three of the outbound integrations.  Not a change in scope, really; just a change in who would do the work, and a small one at that.

We have some standard guidelines for these sorts of integrations, since we do them all the time.  Still, once I had an integration specialist assigned, I reviewed the tasks and estimated hours with him.  We agreed that since two of the integrations were going to the same destination, we’d get some economies of scale in coordinating with the folks at the other end.  We spent some time working the technical details in advance, because unlike our usual time and materials contracts, this one was fixed price.  It had to be correct, or we’d eat the difference.  I then wrote up the change order and sent it to the client, who ran it through their purchasing department.

Once approved, I called Howard, the integrations guy, and reviewed the project plan with him.  We’re task-oriented, and most of us work on two to five projects at any given time.  Consequently, when we have to deliver something can matter quite a lot.  Howard would be able to work in the time slots needed, so we integrated his tasks in with the rest of the project.  Outbound integrations have four basic testing tasks to accomplish:

  • Unit testing, to ensure that the transaction file can be created in the correct format and with the “right” transactions.
  • Connectivity testing, to ensure we can securely pass the file from the origin to the destination, and that they can read it on arrival.
  • Routine operation testing, to ensure the system of record can originate and the end point can accept all change transactions for the time period since the last file was sent.
  • A full replacement, where we send current state for all.  This is only used in case the receiving end needs to recover from some disaster, but we still need to test for it.

Howard would do the development and unit testing independently, but for the other tasks, he needed to coordinate with the folks at the receiving end, and he needed some meaningful test transactions.  So we scheduled his connectivity testing to end at the same time as the unit testing by the folks configuring the system of record, and the routine operation testing to occur at the end of positive system testing (“The Happy Path”).  Then he’d run the full replacement at the end of negative system testing (“The Trail of Tears”), since all other functional and integration testing would be completed.  Using these task dependencies allowed us to track any changes in dates without a great deal of fuss.

We’re having some internal discussions around change orders and how to track them in our time keeping system.  I lean toward adding them to the existing project as a task, while some other folks want to set them up as separate projects.  This is an important consideration for tracking financials and for contract administration.  The logic of using a separate project is to allow invoices to be prepared against the change order, while the logic of setting them up as additional tasks is to simplify time keeping and administration for the folks on the project.  In this case, since it’s a fixed-price contract, invoicing isn’t a consideration, since we’re invoicing based on milestone deliverables, so I’ll take the task approach.  But I’ve used the project approach in the past, when it was appropriate.

The goal for managing change orders should be to minimize the impact to schedule and administration.  In a case like this, where the reason for the change was to transfer risk, you want to avoid creating new risks.  Obviously, Howard and I still have some work to do, but we’ve started this change off on the right foot.

How Would You Explain the iPad to Benjamin Franklin?

Posted on by
3

Benjamin Franklin was indisputably one of the greatest minds of the 18th Century.  Scientist, inventor, journalist, publisher, author, lecturer, diplomat, and mentor to great men.  He wasn’t just the sharpest tool in the shed, he was the whetstone who kept a lot of the other tools sharp.  So, if we were somehow able to transport him to the present day, how would you explain the iPad to him?

“Any sufficiently advanced technology is indistinguishable from magic.” – Arthur C. Clarke

If you were to demonstrate an iPad to an intellectually undistinguished member of the football team of your local high school, he’d be able to use it in a matter of a few minutes.  He’d have no trouble understanding how to use the various gestures to navigate, select applications, and so on.  He’d be able to check his Email, download music, and so on.  And he’d learn quickly, because he won’t care about the technology – he’ll only care about doing things.  He’s grown up around digital music, instantaneous communications, battery powered devices, displays, and search engines, so he has the context to use it in the way the designers intended.  He’s easy to train, and he’ll learn independently.  But there’s a limit to what he’ll actually accomplish, because he’s not interested in how.

But our newly resuscitated scientist is an altogether different case.  He’s famed for his experiments with electricity, but has never seen even a simple device powered by a battery.  His writings are quoted even today, but the concept of keyboards and typing came along nearly a century after he died.  In his day, communication was something one did in person, or in a letter.  Music was performed for small audiences in the same room, until late in the 19th century, when someone figured out to record it, and the 20th century, when someone figured out how to broadcast it.  Mr. Franklin won’t understand anything of what you’re trying to show him, because he simply doesn’t have the life experiences needed to provide context.  But he’s a man of boundless curiosity, so he’ll interrupt your every sentence with a question about how.

Mr. Franklin is going to get frustrated, and so are you.  There’s just too much of an experience gap to bridge, and maybe you need to start him off with something simpler, like a flashlight.  You understand how a flashlight works, even if you don’t know anything about battery technology – just be sure you don’t show him a light with an LED bulb..  Then you show him a microwave oven, but the man who invented the Franklin Stove doesn’t understand how to heat food with gigahertz-band radio waves, because he doesn’t know what they are.  But he’s truly interested in knowing how it works, even if he’s not particularly interesting in nuking a frozen burrito for lunch.  He’s not stupid, by any definition of intelligence, but he’s definitely not ready for this explanation.  And maybe you don’t know enough about cavity magnetrons to answer his questions.

If your project plan includes training, be sure you conduct an analysis of the backgrounds of those who will require training, and ensure that the materials, delivery method, and training approach matches their experience level.  Consider providing background instruction, or even remedial training to a subset of the group, if it will help them get up to speed with the rest of the learners.  Because it’s not about how smart they are; it’s about whether they can put the information in context, acquire the needed skills and understanding, and make use of it.  You probably won’t see the distinguished (and long-deceased) former Ambassador to France in the class, but there’s no point in setting up a smart person for frustration.  Or the presenter, for that matter.  Or the rest of the class.

Multiple Phases, Multiple Timelines

Posted on by
2

I’m about to begin planning for a new project.  This one’s a bit complicated, in that we’re going to roll out different functions at different points in time.  Each go-live will be the culmination of a phase, and of course, each phase includes various stages.  Of course, there will be two major upgrades during the course of the overall project – this is Workday, after all, and they do three a year.  Even better, we’re doing both U.S. and Canadian payroll, so we have to figure out how to run parallel tests against the two current payroll systems.  There are a total of four systems with current data to be converted, plus a bunch of integrations to other system to be developed.  There are even several completely new integrations which will replace current processes that are entirely manual.  Does your head hurt yet?

Obviously, I need to look at this graphically in order to identify the interactions and possible dependencies.  So, I used Visio to plot a view of the timelines of the four phases and the two upgrades.  The next step is to identify the deliverables for each phase, build a WBS, and then try to schedule it out.  Along the way, I need to develop a management plan for the various implementation tenants (Workday-speak for “instances of the software”).   I’ll also need work with Scott, the Conversion God, to figure out the details of migrating phases 2 through 4 to a working production system.  We do it when we need to, but three times in four months will require some detailed planning.  Especially for the payroll phase, as we bring in year-to-date balances from multiple sources.

You might see some more posts on this project, as it evolves and as time permits.