InfoXchange -- ICCA-Boston Newsletter
| March/April 2008 Volume 4 , Issue 1 |
IN THIS ISSUEFrom the Board From the Editor:We would like to encourage anyone to submit articles to the ICCA Greater Boston Chapter newsletter. If you know of anyone interested in free publicity, ask them to write an article of any size or topic pertinent to our organization for submission in the next issue of our newsletter. The good news is the smaller the article, the better, since long articles are hard to read on-line.We are very open to ideas and suggestions regarding article topics in all sections of the newsletter, including: Local or Chapter Announcements; Articles; Member-to-Member Spotlights; Member-to-Member News; Mentor's Corner. Submit ideas or articles to:Song HanManaging Editor, Newsletter newsletter7@ icca-boston.org Next Deadline:April 21, 2008 for the May/June IssueBoard of Directors:President Robert Goodearl Vice President Gloria Metrick Treasurer James Connell Secretary Michael Kibler Past President Norman Daoust Click for Board contact info |
If you answered yes to any of those questions, consider joining the chapter's board of directors! Our election will occur at the March 25 meeting. If you'd like to nominate yourself, if you'd like more information about the Board of Directors positions, or if you'd like to know how being a member of the board can help you accomplish any of the above goals, please contact Larry Bressler, the chair of our nominations committee, at election@icca-boston.org. You'll be glad you did! By Norman Daoust, Past President, ICCA-Boston Mentor's Corner Five Warning Signs of Misalignment between a Project and the Business StrategyPart of my consulting practice is to perform assessments. Sometimes, those assessments discover misalignments between the software projects and the rest of the company. Misalignments show up as “problem” projects, “inadequate” testing, “slow” projects, and other typical problems in the software industry. It turns out, though, that many misalignment problems can be solved by small changes in how the projects start, work, and finish. With 14 years of assessments under my belt, I've seen several different issues. Here are the top five issues I look for when assessing organizations, especially when looking for misalignment between projects and the business strategy. 1. Lumping all the business stakeholders into one category, “the business”. Yes, the project teams exists to satisfy business needs, but calling all the stakeholders one name doesn’t help differentiate what each set of stakeholders requires for a given project or system. The finance people want one thing, the sales people want something else, the marketing people want something, and there may be other groups with individual wants and needs. In my experience, the lack of stakeholder differentiation leads to two problems in requirements: incomplete requirements definition, and inadequate ranking of requirements. Although the stakeholders are lumped together, the project team does not know enough of the requirements, nor do they demand that the stakeholders agree on which requirements to implement first, second, third, and so on. 2. There is no pictorial description of the system. As software people, we assume that only the project team would use a picture of the product’s architecture. However, when architecture pictures exist, managers can explain the workflow and data movement to each of the stakeholders. And other project teams can understand what your team is doing. The various business people can then understand the effects of their requests on the rest of the system. 3. The various stakeholders can only see work in progress when the product is formally released. A project team has several techniques to show stakeholders how the system is shaping up. The more traditional approach is to use a staged delivery lifecycle, with interim (monthly, bi-monthly, quarterly) releases. However, a project team can choose to implement an entire feature at a time instead of implementing architectural components at one time (implementing by slice), especially if the team is willing to use an agile lifecycle. 4. Developers and testers don’t have enough domain expertise to adequately create and test the system. Domain expertise comes in two flavors: problem-space and solution-space. People who have problem-space domain expertise understand the problems the system solves. People with solution-space domain expertise understand the internals of the system, for how it solves those problems. Without understanding the problems the system solves, or how the system solves those problems, the developers can’t create systems that meet the needs of the stakeholders—and the testers can’t test those systems. 5. Inadequate data gathering and explanation to the various stakeholders. When organizations don’t have data about their projects, they use intuition and gut feel to make decisions. But everyone’s intuition is not the same. And everyone’s risk tolerance is different. Those differences mean that people try to talk about the issues, but they come to widely different conclusions with no data to help them arrive at common ground. A project team needs to create a project dashboard and explain what the data means—again and again and again. Summary You may not see all of these warning signs of misalignment. But if you see any of these signs, you’re seeing a problem with alignment between a project and the business. Review these warning signs to make sure you’ve identified all your users, shown the system flow, can show small pieces of system completion, hire developers and testers who can do great work and explain your project state. You may still have problems, but these issues will probably not be due to alignment. By Johanna Rothman Rothman Consulting Group, Inc. Johanna Rothman will be presenting "Assessments: A Consultant's Tool for Organizational Change" at ICCA Boston Chapter's meeting on March 25, 2008. Toolkit for Consultants IP Ownership and LicensesFirst, a Disclaimer I'll start with a disclaimer first — I am not a lawyer. The ideas we'll explore in this article come from my own experience in the software industry. Next I'll disclaim my disclaimer: I don't need to be a lawyer. I'm not dispensing legal advice, just promoting awareness of legal issues. Besides, it's OK to wear the "legal" hat yourself once in a while. If you're an independent consultant running your own show, you'll do well to understand the impacts of applicable law on various aspects of your business. Where your own business and interests are at stake, you'll find no one more motivated than yourself to make sure you research what you need to make the right decisions for your business. Don't get me wrong — working with lawyers speeds up your self-education process. Like professionals in many highly educated fields, they tend to know their stuff. Because they can save you time, they're valuable . My point is simply that they're not invaluable . You can research what you need to know. The Law is for everyone, By the People, For the People, and the promise of other safeguards that Americans expect! Who Owns It? One very important thing to consider for your business is the question of what rights you and your clients have to your work product. Employees of corporations generally assign all ownership rights of everything they produce on the job to their employer as part of their employment agreement, in return for compensation (i.e., a salary). The phrase "Work for Hire" indicates this sort of arrangement, "We pay for your time, we own whatever you produce for us." As independent consultants, you have flexibility to negotiate that sort of thing. The standard form contract provided by the ICCA starts at the other extreme, with a "Use of Work Product" clause, which basically says that you own whatever work product is produced under the contract, and you graciously allow your customer to use it. Give and Take on Intellectual Property (IP) You may find it takes convincing to get clients to understand why they won't own the work product they're paying to produce. I have run into this often over the years, and have always managed to bring clients — even big ones — around to my way of thinking. Sometimes it took a little extra explanation, other times it contributed to months of delay in contract negotiations. I never lost business because of it, though I was always willing to. As an example, I'll share my own "compromise" approach that has worked for me. First, I thought about the business model to determine whether fighting for IP was important. I then viewed the situation from the perspective of a prospective client, understanding what I might do for them, and considered whether they had good reason to fight for IP. Some clients, especially the larger ones, fight for IP simply out of habit, because they like sticking to their standard form contracts. My business model was built around the idea of setting up best practice software development environments — setting up CM systems, build systems, bug trackers, and integration various systems together into a software production line — all pretty generic stuff. I wasn't selling any formal products, but I realized it took time to develop mountains of scripts and tools that I wanted to reuse from one client to the next, rather than re-invent the wheel each time. However, I also knew from experience that, once I got started working with a client, I sometimes got involved in things that didn't fall into the category of "generic software development process." I realized my challenge was to come up with contract language (and a corresponding software license) that allowed me to grow my business by protecting the IP of generic software development process things that I did for clients. However, I also needed to make clients feel comfortable using me or any of my team as generic resources, should their roles expand beyond the realm of generic software development process stuff, perhaps even supporting development of whatever their core product was. Making them feel comfortable meant making them understand that, if they happened to use my or my team for anything outside the scope of generic software development infrastructure, that such work would be Work for Hire, and they would maintain the IP. Giving them that protection allowed me to grow the business by more easily mining more work from existing clients. Had I tried to push a simple "I own it all" IP clause on them, they would have been motivated to limit the scope of what I did for them solely to the generic stuff. I explained to hiring manages and corporate legal departments many times that ownership of generic software development information (scripts, tools, integrations, processes, and even white papers) was absolutely essential to my business model — and moreover, was completely inconsequential to them. I also stressed that, should any of my team be "the right person at the right time" to help with something that was outside the scope of generic process, they could do so with confidence that they would own any related IP. While it sometimes caused delays in getting deals signed, it always worked. Part of the reason for the perfect batting average was that I had accounted for their concerns, ensuring that they would own the IP should any of my team work on things outside the scope of generic software development process. And I was generally able to make them realize that I was growing a business, not just providing bodies and hours of time. Selling Services vs. Developing Products Are you selling your expertise (or that of your people) and skills by the hour? Are you trying to build a business, reusing not just ideas but actual code base over the years? Or, as in my example, both? If your primary business model is selling hourly services, fighting for IP may be counterproductive, because in many cases you'll have to justify your need to own IP to clients. However, without ownership of your IP, your ability to grow your business will be limited, because you won't be able to build a reusable set of intellectual property that you can sell over and over again, each time with less effort than the first time you produced it. The word "Products" here should be interpreted in a wide sense. I'm not just talking about formal software products. A couple of useful scripts, a few paragraphs of useful prose, anything you might reuse, either by itself, or as part of a larger assembly of things you might use later, are all worthy if IP protection, because they are things you can build upon. Copyrights, Licenses and EULAs Once you have established your need for IP protection, the next step is clearly communicate it to users of your product — and not just to project managers or their legal departments who see the contract paperwork. It is important to ensure that your work products are properly labeled. Be sure to always use Copyright © statements in any code, writings, or articles you produce, even in cases where you assign the copyright to your client. You might go a step further if you're delivering software, distributing a license with your software, and referencing it in the copyright. For example, you might have a simple copyright like:
A book on this topic I recommend is Legal Care for Your Software, by Daniel Remer and Robert Dunaway (ISBN 0782117295). By C. Thomas Tyler Consultant Perforce Software, Inc. Former President, ICCA Greater Boston Chapter Founded in 1976, the Independent Computer Consultants Association (ICCA) is a national not-for-profit organization of independent computer consulting firms sharing the highest ethical and professional standards. The ICCA Greater Boston Chapter Mission Statement: The Greater Boston Chapter of the ICCA supports and encourages the growth of individuals and small firms in the business of computer consulting through education, networking, advocacy, and the exchange of ideas and knowledge among peers. The ICCA offers great services and benefits to its members including business and health insurance, marketing programs, a National Conference, standard form consulting and subcontracting contracts, and many discount programs. For additional information regarding the ICCA or to search the National Membership Directory, visit the national website http://www.icca.org or the Greater Boston Chapter website http://www.icca-boston.org Legal StuffPublisher: Greater Boston Chapter of the Independent Computer Consultants Association, http://www.icca-boston.org Copyright 2008, Greater Boston Chapter of the Independent Computer Consultants Association This newsletter may be distributed without charge as long as it's distributed in its entirety. Individual sections and portions may be distributed with permission.US Mail: ICCA, Greater Boston Chapter 11131 South Towne Square, Suite F St Louis, MO 63123-7817 |