Now what are we going to do?
Does the headline sound like a familiar refrain? I have worked with a lot of companies over the years and they are not that different from me. Typically I’m moved to action far more quickly if there is a crisis than if not. So what is the point of this article you ask? Well, it’s about protecting your assets — your IT assets — before there is a problem.
Having worked in-house, I was fortunate enough to have had the opportunity to see and be involved in the mechanics of how “business” and legal interact in an up-close-and-personal way, which was amazing. Prior to working in-house, I always had the feeling I was standing at the window looking in.
Don’t get me wrong though, inside or outside, the opportunity is there for us to learn and assist, and trust me, there are times when I’m very happy to have that pane of glass. . . . But I digress.
One of the big challenges that tech companies face, is effectively managing their assets — ownership rights (and licensed rights) in technologies. Big or small, there are so many elements that come into play for a company trying to manage its rights, that more often than not, its assets are not on the proverbial radar until there is an issue.
Consider this: your client’s company has just discovered one of its key service providers, a small, three-person shop, has disbanded leaving your client without access to important resources — namely, the only shop in town that knows how to get the company’s web site back up and running because it just crashed under the weight of user load.
Now what — apart from the panic that befalls the tech group now staring down the barrel of a loaded gun in a race against time (and loss of revenue) to figure out how to get the site back up and running before the “big guy” finds out?
When you think about it, technology assets actually come in contact with nearly every business group in a company at some point. In a perfect world, and for the purposes of illustration, the following is the life cycle of a software development project:
1. The president wants a new piece of proprietary load-testing software to be developed so the
company can monitor load and prevent the e-commerce site from going down;
2. legal puts together the necessary agreements, which are negotiated and then executed;
3. human resources hires a new developer for the project, who signs some kind of
“non-disclosure and invention assignment agreement” as a precondition of his or her
employment;
4. the head of the technology group sources a third-party service provider to assist with the
project, and they enter into a software development agreement with the company;
5. a purchase order is submitted to finance detailing the milestone payments that will be made
to the service provider over the course of the project;
6. the developer and the service provider work with a project manager developing the software;
7. the software is developed, tested, accepted, and successfully deployed on time;
8. knowledge transfer has taken place and the developer has downloaded the necessary
information to the development team so the software can be managed, tweaked, and
updated internally;
9. the service provider is paid and provides the project manager/legal with assignments of
rights from those working on the project and hands over the code and related
documentation;
10. HR gets an assignment from the developer (because notwithstanding the rights that the
company might have even without such an assignment, better to have the documentation to
prove it than not); and
11. everyone gets a bonus for a job well done (in a perfect world of course).
But we all know that things never go that smoothly, don’t we.
Deadlines sometimes aren’t met, employees leave and are let go, service providers do their best but software often has bugs that need fixing and ends up costing more time and money than expected, purchase orders are paid late, knowledge is not fully transferred, assignments are not all submitted, code isn’t fully documented or tested, open source is used to get the job done more cost-effectively, and the list goes on.
So how can your clients/tech companies manage risk and still get things done?
There are lots of different ways to manage risk and run a business efficiently, but none can be successfully effected without commitment to the process.
To begin with, there needs to be transparency across business groups and departments. Communication by way of regular face-to-face meetings is a start. This isn’t groundbreaking but even in the best of circumstances is often very hard to stick with.
Knowing what others are working on though, and keeping them up to speed on issues and developments will save time and money in the long run. Also, and probably most importantly, everyone needs to buy in to the process (whatever it ends up being), be committed to working together and following the process, be empowered to perform their roles, and ultimately, be accountable for what they do (or don’t do).
Other considerations:
Project management: Notwithstanding the obvious business reasons for moving projects forward to stay on deadline — no project should ever be started without the necessary documentation being in place.
Statements of work: Should have project details included, including a detailed description of project/deliverables, underlying (i.e. in-licensed) technologies, milestones for development, key personnel, code drops and knowledge transfer, go-live date, assignments, etc.
Purchase orders: Get paid only if milestones have been reached, upon approval by appropriate individual, i.e. in the case of out-of-scope work, change work orders, etc. or upon completion of the project and when code is received, knowledge transferred, and assignments are executed.
Checklists: There should be task checklists for each key person’s role (be it in HR, finance, legal, or otherwise) to ensure accountability to the process.
Compliance audits: If procedures are created and put in place, they need to be followed in order to really be effective, so departments should be regularly audited for compliance.
Project managers: Secure external service provider assignments and confirm with finance before payment is made to service provider, and work with legal on all documentation, including documentation relating to in-licensed technologies.
HR: Needs to ensure that confidentiality and invention assignment agreements are entered into by new employees, and must secure employee assignments upon resignation/termination.
Legal: Keep legal in the loop! So often legal gets information in bits and pieces and is asked to perform at the last minute, so of course it becomes the bottleneck that no one wants to deal with. If legal is able to participate and get what it needs early in the process, it is less likely to impede project progress.
Security: Access to project development “sandboxes,” to the back end of the site should be restricted (need-to-know only, password protected) and logged at all times.
Escrow: Whether on-site or off-site, licensed or developed/owned software (especially mission-critical products) source code (fixed and updated versions) should be secured, whether on an ongoing basis as milestones are met and/or upon final delivery, together with enabling documentation, as well as the right to confirm quality/utility of the code and the documentation.
Documentation: Have a central repository for project-related agreements and other documentation, have a master list of all agreements, and include relevant details of the same if practicable; when completing projects, have a “closing” checklist for each contract/project.
There is no such thing as perfect (except of course in my rose-coloured world), but with the right tools, you can get pretty close if you try.
Sarah Dale-Harris is a lawyer in the intellectual property, technology & interactive entertainment groups at Davis LLP. Her practice focuses on the creation, development, management, commercialization, and enforcement of technology and life sciences-based portfolios and related intellectual property rights. Sarah can be reached at 416-365-3522 or at [email protected].
