Platt Perspective on Business and Technology

If you want your company to be more innovative 8: communication and innovation openness in the face of due diligence barriers 3

Posted in HR and personnel, social networking and business by Timothy Platt on August 5, 2013

Improving a business as a competitive enterprise, and making it more effectively communicative and collaboratively innovative, can be as simple as providing employees with a place where they can come together and talk. My goal for this series is to at least briefly outline an approach for facilitating conversation and the sharing of ideas and for collaboration in a business, as an enabler of innovative excellence (see HR and Personnel, postings 165 and loosely following for Parts 1-7.)

I first began explicitly discussing due diligence requirements for controlling information access and use within a business in this series in Part 6, with a foundation discussion of some of the core issues that come into play when managing proprietary, sensitive and confidential information. I then briefly discussed an in-house driven example of how this works in practice in Part 7, where a business seeks to simultaneously foster and promote active, productive collaboration in developing new and next generation products and services, but where it needs to keep its research and development activities and goals in-house and contained, so as to retain first mover advantage of any productively marketable developments arrived at. My goal for this installment, as noted at the end of Part 7, is to add accommodation of external regulatory restrictions to that discussion. My goal here is to at least begin to outline how a business might more effectively both support open information access where that would create and enable significant collaborative value, while simultaneously meeting externally defined due diligence and risk remediation requirements in place.

As a case study example, and to take this discussion at least somewhat out of the abstract, I cite a specific development and innovation situation that I have faced in my own work experience: developing a new, next generation customer relationship management (CRM) software package for in-house use as a proprietary information management resource.

• This software package was developed in-house under the auspices of the Information Technology department, and by a combination of in-house programmers and full time consultants who had signed confidentiality agreements. In-house sourced participation from affected departments whose staff members would use this new system were also brought into this development process to provide feedback and insight on product requirements for this new software, and both to insure the right functionality features were included and that effective usability features and user-facing designs were built in too. Supervisory management and oversight was all drawn from in-house.
• This new package had to be tested out as a work in progress, and both for code debugging and for validating it overall for its task-specific usability and for meeting real-world day-to-day task requirements – with “usability” and “real-world” defined for this as real end-users would define and judge those performance criteria. As a brief aside, I have long referred to software that does not pass this type of test as being “designed by programmers and for programmers” – i.e. if anyone else tries using it, deviating in any way from the one pattern of expected use that the programmer has built for, everything crashes and fails. Making software that works and that gives accurate results can only be half of the answer to a development challenge of this type. Real world users are not generally computer programmers and they can and do and will get very creative in how they see and use their tools at hand. They can be counted on to see the software that they use differently than any programmer would, and they will use it differently than expected by software developers and coders in general. So flexibility in how you can use software, and particularly functionally complex software has to be accommodated for too, so that real end-users can do their jobs and focus on what they are using this software for, and without having to focus on the tools they use instead. With that digression in mind, I note that a group of real-world end-users were needed for testing and from early on during the initial design and planning steps of this development project and through to alpha testing and on into pre-release and even post-release beta testing too.
• And this is where external regulatory guidelines and legally mandated information access restrictions enter into this narrative. This software had to be tested using real data concerning real people who were entered into the company’s existing databases as customers and pre-sales contacts. Among other things, this meant that the non-development team testers who worked with this software as it was being developed, all had to be people with authorized access to this customer data anyway. That made sense regardless of legal regulatory issues because it is the people who routinely access and use this data who would use this software anyway so they would already be trained as to the importance of maintaining personally identifiable information confidentiality. Development team members had to be brought up to speed on this too, where that definitely included specific guidelines on where any sample data could be electronically stored and that physically taken.
• Open collaboration in this, as in the more strictly in-house access restriction system example of Part 7, meant finding and vetting and including the right people in this team, but no one else. And it meant limiting customer data access within this overall team to just the people in it who actually needed to see this data too, though proper due diligence had to assume that all people actively involved in this project might gain access to and see at least some of this customer data as a part of their normal work.

This, up to here, has only dealt with one possible source of legally mandated limitation as to who can gain what level and type of access to what data. There are other bases for establishing outside legally binding access limitations to information sharing, and one that comes immediately to mind is licensing and business to business contracts.

CRM software generally includes in its back-end, database facing side, filtering and sorting algorithms for finding the right records and for a wide range of possible database search queries. Businesses sometimes gain access to patented or otherwise proprietary algorithms and some excellent filtering and sorting algorithms are available for licensed use. If this project had made use of this type of building block resource, access to human readable source code for the specific software module that encodes these algorithms would be restricted to programmers required to see this and work with it as part of their work on this project.

And this brings me to the question of how specific people would be brought into what collaborative groups and into what teams, and how they would be vetted and trained so as to meet overall due diligence and risk management requirements. I will delve into that in my next series installment. Meanwhile, you can find this and related postings at HR and Personnel and Social Networking and Business.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: