By Edan Puritt
Ta-da! That’s it. There’s the fanfare announcement of Askari’s IM blog starting. This blog will add genuine sparkle to the plethora of information management gems and imposters floating on the web. Just wait, we are unique. (Groan, I hear it, another one?) Okay, let’s dig in. Government project. What comes to mind? Cheaper, faster, and more sustainable delivery of a service? Not likely, you’re thinking. Well, it is possible. Better yet, it has been done. We’ve done and continue doing exactly that at BuyandSell. Imagine, producing the same quality service or product more efficiently, more cost-effectively, and with less concerns about sustaining that effort. That’s what’s going on in procurement and tenders at Public Works and Government Services Canada. That’s our approach to IM. “Your BuyandSell.gc.ca is open for business.” That was the slogan last June, just about a year ago announcing a major shift in how our government buys and sells or procures and tenders for projects. Happy Birthday BuyandSell! The BuyandSell project found its origins in a business need to improve the procurement and tendering process for the Government of Canada. The senior manager responsible in the area had a vision for an easier, cheaper, and more business responsive solution. This coincided with a larger trend to start using some open source software as a standard for project implementations. At Public Works, the BuyandSell project has been built using Drupal open source software which brings a myriad of opportunities and challenges, but that is the topic of a different blog, “Implementing Open Source Solutions.” Ok, I admit, maybe three or more different blogs. I should perhaps take a moment to say that I use the term Information Management or acronym IM in the widest possible context. It’s a very large umbrella, and there is plenty of room for all of us who toil on the many aspects of getting bits and bytes harnessed and moving digital activity forward. And yes, even though one particular group sheltering under that cover has traditionally called ourselves Information Management professionals, we are all generally concerned with the lifecycle of information. So how is the IM approach used on this project different from the standard approach? We’re still concerned with managing risk, managing the lifecycle of information, providing solutions, and shaping the future. What’s our angle? It’s simple. We build today what we want to support tomorrow. We use and share common data standards and we determine the provenance of every piece of data. Then we buy the data once, and use it many times. This careful pre-planning allows us to amortize the creation, maintenance, and deletion of that purchase over many uses. When we started, we found multiple systems that contained instances of the same information, i.e. a customer’s address. And yes, there were different addresses for the same customer. Which one were we to use? Which one was correct? How many people were maintaining the same information and how frustrated were our customers at continually updating the information each time they touched a different part of the organization? Just like at home, it requires resources to buy or build something, resources to maintain it, resources to store it, and resources to eventually dispose of it. Now, I would argue the greatest risk of all is the possibility that with the increasing instances of similar multiple things, we will use the wrong thing to make a decision. Of course, maybe we will just share the wrong thing with someone else, for that person to make a decision with damaging, cascading impacts. We looked at each business function, and then built interoperable modules for each major activity. It allows us to maintain an environment of continuous improvement with new iterations happening every two weeks. The constant changes and upgrades allow users to see their concerns and suggestions implemented without PW facing the real fear and cost of tampering with an entire enterprise system. So, one program will accept procurement information from acquisitions officers and then hand that data to a separate program that displays the information for the Canadian public. So what happened specifically at BuyandSell? We divided developer function from business function, with an emphasis on business people getting their jobs done. This approach allowed for a relatively easy transition to staff ownership and expertise and a move away from the developers’ ongoing involvement. The developers, while skilled with software, are not as well versed in the art and science of procurement. For business reasons it was important to get the core business work back in the hands of procurement specialists. Moreover, it means that as our developers come and go on the project, the ramp-up speed, and, therefore cost, is greatly reduced. It’s bad form to repeat, and I can’t just raise my voice, so let me just say, PLAN to have to replace your staff. If they are inadequate to the task, you will want to replace them, and if they do a great job, they will learn, be better, and be ready for bigger other challenges. Either way, the bad ones, and the good ones, leave. Then they need to be replaced. We know what skills are needed (maybe 10 years of PHP, 10 years of Java, or 5 years of Drupal) but how long will it take until they, and the client, are confident enough to give newbies to the project real access? It costs just as much to pay them to learn as it does to work on the real thing. So, the more generic the code, the faster they can be productive, and the more modular, the lower the risk of catastrophic failure should they make a mistake. The staff of Acquisitions Branch told us how they do their job, and then we developed a solution to meet those needs. The difference in approach manifested in less than a day of training being required. Less than a day: that’s keeping the business need front and centre. The IM happens in a way that complements the business functionality rather than disrupts it. We ended up with a solution that is managed and run by knowledgeable business people, maintaining fewer information objects (no information redundancy), and based on common standards. Those common standards allowed us to easily connect to other systems, both within our department, as well as with the procurement systems of other departments. When Shared Services chose a different product than Public Works to develop their tender documents, and then asked if we could still publish their opportunities, the answer was yes, … and that it was easy. We shared our data schema to which they export their data. We import that data, as we do with Public Works, and as we could do with any other solution. It’s seamless because they continue to work in a familiar environment and the business programming need happens behind that. Because we built using open data standards, and we buy and maintain each piece of information once, our solution works. It is simple and easy to maintain. Actually, it is better, because it is easy to improve. Undoubtedly, we developed a cheaper, faster, and more sustainable government project. That’s right, the project is BuyandSell. It is successful, and it is a government project.