So what’s all the fuss about? It’s actually a really significant change to the rules around personal data, and it really does affect you.

Here’s a quick summary:

• The EU says the changes attempt to “harmonize data privacy laws across Europe, protect and empower all EU citizens data privacy and reshape the way organisations across the region approach data privacy.”

• One of the more controversial impacts of the new rules, and the reason it has such a world-wide impact, is what they call the “extra-territorial applicability“.  This means that it applies to all companies worldwide who are dealing with information about people residing in the EU, even those simply offering goods or services to EU citizens. It hits everyone and it’s huge.

• One of the key changes is around consent. Basically if a company is going to store or process personal data such as names, email addresses and the like, it needs to have explicit consent. The small print in the middle of a 10-page “terms and conditions” aren’t enough – it has to be in complete plain English.

• The method of consent has to be recorded as well and proper records kept. This is significant – for example, if you have a mailing list you need to be able to show when people opted in and how.

• The fines are huge too. Companies can be fined up to 4 percent of their annual global turnover for breaches, with big fines for even seemingly minor issues.

• Companies must now also tell people if they’ve had a breach. We’ve seen a heap of this lately – people’s information being stolen and companies keeping it quiet to try to avoid reputation damage. Do that now and it could cost 2 percent of global revenue.

• Other changes are familiar to kiwis, such as the right to obtain (free of charge) any information that is being held about them. That’s been a part of NZ’s Privacy Act for a long time, although the EU law goes further.

• There’s heaps more as well, such as the controversial “right to be forgotten” This basically gives EU citizens the right to have Google, for example, remove references to them on searches. And again, the rules apply globally – not just to EU companies.

• The new rules also put into law the concept of “Privacy by design” for software developers. Basically software developers have to show they’ve built privacy into software from the ground up, not just tagged it on in the end. This has been a long time coming.

So some really important things to think about from a IT Professional perspective as well, even if you’re not based in the EU.

View the full regulations here

ABOUT PAUL MATTHEWS//

Paul Matthews is chief executive of the Institute of IT

IITP has been working behind the scenes over the last few months helping MBIE develop a new approach to software procurement for a new project to develop an Emergency Response System, which will include an app and related technology. While this is a one-off and not technically a pilot or trial for the new approach outlined below, if the project is successful, we believe we’ll see further developments in this space and probable wider adoption.

So what makes this procurement different?

Qualifications-based selection
The procurement process for the project is based on a variant of Qualifications-based Selection.

On paper, QBS is considered to more compatible with Agile development than traditional procurement processes and has been highly successful in other industries overseas when dealing with complex and higher-risk projects, similar to the characteristics of bespoke software. The US federal government has used QBS for complex engineering projects for many years and in NZ, a variant of QBS (called the “Alliance Model”) is used for large and complex roading projects where innovation is needed and the detailed requirements are unknown at the start.

Under QBS, the entire focus of the procurement is to find the best provider(s) to work as a partner on the collaborative development of a solution. Price isn’t considered, and in fact is explicitly excluded from consideration during the RFP phase. The only consideration is who would be best able to work with the client and deliver a solution, based on factors such as previous experience and proven results. Importantly, the client is procuring a partner to help develop a solution, not a product.

The downside of QBS is that it favours providers with experience, thereby making it a little harder for those without a track record to be selected. However, given its use for complex or higher-risk projects (in this case, emergency service software), this ain’t a bad thing. Innovative providers without the breadth of necessary experience can still get a look-in however, with the RFP explicitly allowing consortia or alliances and the requirements being applied to a consortium accordingly.

Outcomes-based collaborative approach
The requirements of the final product aren’t specified in the RFP other than in fairly general terms including a couple of bottom-line features and outcomes. The intention is to take an outcomes-based approach; MBIE and NZ Police don’t have a monopoly on good ideas, and the whole structure is designed to support and encourage innovative thinking from potential partners.

As outlined above, the intention is to find the best partner or partners, and to then work with them on designing a potential solution. The clients can then harness the experience, ideas, and innovation of the industry, rather than killing innovation by attempting to specify exactly what the solution will look like upfront. There are also workshops planned where potential partners can explore possibilities and fairly freely discuss opportunities and options – prior to the RFP closing.

By talking in terms of outcomes rather than specifications, potential partners are free to do something really special, without the restrictive bounds of traditional procurement. The hope is that this will lead to an outside the box solution, possibly quite different – and superior – to what the client might have been thinking initially.

Proof-of-concept “bake-off”
The selection process ranks respondents based on set criteria designed to find the most compatible partner which can show it can deliver results, rather than procuring a product or solution.

Via the QBS process, the 2-3 most compatible partners are selected and will then participate in a proof of concept “bake-off”. The client will work collaboratively and directly with each partner to start to put some ideas on paper, with the partner designing what the outcome and solution might look like as a concept.

The partners will then present their proof of concept and one will be chosen to develop the solution. However all partners in the bake-off will be paid whether selected or not, assuming they see the process through and deliver on the proof-of-concept requirements, via a “grant” of $75,000 each.

The client then negotiates the development terms, including cost, with the preferred partner. If terms can’t be reached, the client will likely commence negotiations with the next-placed provider and, assuming an agreement can be reached either way, development of the full solution will commence.

Agile approach
Compatibility with Agile development is implicit in the design of the process, and while Agile is certainly not mandatory, compatibility has been considered at every stage of the RFP and development process.

We know two things about Agile and procurement: (1) it generally leads to far better results in software development, for example with Standish finding it leads to 1/3 of the project failures of traditional waterfall-based methodologies, and (2) genuine Agile is not particularly compatible with traditional “price and specs up front” procurement.

We also know that when price-up-front is mandated, it almost never equals the cost of a project at completion, especially for complex projects. So why do we continue to use it as a selection criteria in software procurement? We believe the evidence shows we’re far more likely to see good results by worrying about cost only once we actually know what the solution is really going to look like, with providers focused on innovating rather than selling during at least the initial phases.

Focus on the people delivering solutions
While not unique to this RFP, strong emphasis has been put on the actual people who will be involved in delivering the outcome, including their track record, background, knowledge, qualifications and experience.

From IITP’s perspective, it has to be about the people; people and teams deliver solutions, not brands. We’re very pleased to see this focus and while there isn’t a requirement for Chartered IT Professional NZ accreditation from respondents, we would certainly hope to see people at that level involved in leading the project.

Intellectual Property
The government will be granted a permanent license to use any IP generated during development, however the resulting IP will be owned by the partner. This means the partner can freely turn it into a broader product or service and go forth and export – sell it to other Governments, bundle it into other offerings, evolve it into something else, or even open-source it if they’d prefer.

The long and short is that rather than it being seen as a one-off, our hope is that the project will turn into something far larger and contribute to the development and growth of the NZ industry.

A major step forward
We believe the approach taken is a major step forward in the procurement of software in New Zealand, and we’re seriously impressed with the collaborative approach and focus on industry-supported innovative procurement from MBIE.

Is the model perfect? Probably not. But it’s a real and serious step towards addressing many of the well-documented problems with software procurement by government. We see this as a real opportunity for our industry and strongly encourage innovative app developers to seriously look at being a part of it, either on their own or in partnership with cloud, infrastructure or other providers.

View the summary on GETS here.

IMPORTANT NOTE: This article is for information only, and should be considered good faith opinion only. IITP is commenting on the process contained in the RFP released yesterday, and is not procuring the solution – that’s MBIE and NZ Police. Thus, where anything written here differs from the detail in the Request for Proposal, please consider the RFP correct.

ABOUT PAUL MATTHEWS//
Paul Matthews is chief executive of the Institute of IT

In 1907 a group of engineers and bridge builders in Quebec, Canada, embarked on an ambitious project to build the longest bridge in the world. But before the bridge was completed it was to cost almost 100 human lives.

On August 29th the partially built bridge collapsed, killing 75 workers and injuring another 11. A Royal Commission of Enquiry found a lack of experience of the type and size of bridge and clear mistakes had caused the disaster and held the designer and consulting engineers responsible. Construction began on the bridge once more in 1916, but disaster struck again, when the central span was being raised into position, and fell into the river killing 13 workers.

The managers had been made aware of the problem that caused this second collapse a full six weeks prior by the engineer responsible for the construction of the centre section, but hadn’t taken any action. All in all, 88 people lost their lives to predictable failures.

So what does all of this have to do with IT and technology today?

It was after this double tragedy that the concept of the Professional Engineer was born. Engineers realised that they couldn’t continue to have such devastating failures caused by inexperience or not following reasonable standards of practice. And they could no longer tolerate decision-makers ignoring their professional advice.

A similar sentiment has been growing in the international IT community since 2008, when the national tech professional bodies from Canada, the UK, Australia, South Africa, Japan and elsewhere came together to discuss whether it was time for the IT profession to also put in place minimum competency standards. Since then, all of these countries, and many others have done just that.

In New Zealand’s case, the road towards the Chartered IT Professional accreditation that was officially released in February began when the IITP (then called the NZ Computer Society) released a 2008 discussion document outlining a range of problems in the industry and calling for the profession to form independent competency standards to address them.

As well as continual significant failures in major IT projects in both the public and private sectors, some of the issues highlighted included the global IT skills shortage; significant reduction in technology undergraduates and in the percentage graduating; negative perception of IT as a career amongst youth; and lack of retention of skilled individuals in New Zealand.

In other words, our bridges were falling down and we needed to do something about it. New Zealand’s response, run by the Institute and named IT Certified Professional (ITCP), was released in late 2009 to great success.

Up until that point, IT was almost the only vocation or profession remaining without a set of independent benchmarks outlining the minimum expected standards of skills, knowledge, ethics and professionalism for people operating the field. And we’re not just talking about the established professions such as accountants and lawyers here. Almost every area you can think of, from plumbers to librarians and architects, has minimum standards in the form of an overarching professional certification. The reason for such accreditations is that there is a real difference between someone who knows what they’re doing and someone who doesn’t. Professionals have the right to differentiate themselves and a responsibility to come together within professional bodies and define minimum standards.

In February the IITP converted the ITCP to the Chartered IT Professional NZ, issued under license from the UK-based BCS, the Chartered Institute for IT. It also introduced a new Certified Technologist accreditation for those in the first few years of their career. The reason for the change is to increase the recognition of Kiwi IT professionals both in New Zealand and around the world, and to provide credentials that are immediately recognisable by the public.

Those accredited have committed to adhering to standards of professional conduct and ethics and have agreed to be professionally accountable if they don’t. In return, they have the weight of the entire profession behind them when they say that a project can’t proceed because if it does, the bridge will fall down.

ABOUT PAUL MATTHEWS//
Paul Matthews is chief executive of the Institute of IT