• No results found

Sourcing of print software

CHAPTER 5 : OSTENSIVE AND PERFORMATIVE FLEXIBILITY VIA

5.3 Sourcing of print software

5.3.1 Overview of the case

This section is about the second sourcing exercise that the project team completed to purchase print software that would fit the needs of the new managed print service. The routine started off with the selection of the procurement framework. For this activity, at first the NPA option seemed the obvious one as it is a framework specifically for managed print solutions in the public sector. However, eventually the project team opted for an open tender. For the preparation of the ITT document, besides doing most of the work internally, the team also opted to obtain input from print specialists (hereafter known as Consultants) and gain insight from site visits in order to finalise the document. Once prepared, the ITT approvals were initially required from the Committee only, however it was later decided to extend the approvals to all the Board members.When it came to

135

the evaluations, the interview session followed a demonstration-type format, more specific in its purpose compared to a conventional presentation. As for the evaluation criteria, several options emerged in terms of which criteria would have least weighting or impact e.g. support, costing, and technical ability.

5.3.2 How the options emerged Project creation

Similar to the previous sourcing exercise, the first part of the routine was to decide on what procurement framework to use. The initial option was to use the NPA framework, however eventually the Committee opted to go for an open tender i.e. without the use of a framework.

In one of the earlier meetings, the NPA framework was suggested as it is designed specifically to cater for the public sector. Thus all suppliers on the framework would already be familiar with the needs of a public organisation such as PublicCo. Furthermore, it was thought that the NPA framework would provide greater flexibility in terms of the list of software the project team can choose from. Because of these reasons, it made sense to use this framework. Furthermore, when the Procurement Head had an informal chat with a potential software supplier, she got the impression that they assumed PublicCo would use the NPA framework as the obvious option.

“Well not from what these guys [potential supplier] said this morning, [if we go] down the [NPA] route, we’ve got flexibility…to some extent obviously…You’ve probably got it narrowed down in your head to either [SoftwareP], [SoftwareE], possibly not [SoftwareS]”

(Procurement Head – WC meeting 4)

Mid-way through the Print Project in the 10th month, as the Committee started to focus on the sourcing of the print software, they still suggested the NPA framework as the best option as it had suppliers that were manufacturers, as well as non-manufacturers. Thus, the framework did not limit the choice of software that could be selected, as pointed out by the Technical Head in the conversation below:

Procurement Head: But remember [the Consultant’s] recommendation is to not get too excited about [SoftwareP], because he reckons that some of the others are just as good. And my concern is that we

136

don’t go down a route that restricts a list of manufacturers, have to make sure that they all support anybody on the [NPA] framework. So that’s sort of deciding we’re using the [NPA] framework

Technical Head: I’m just picking that because it has got everyone on it

(WC meeting 15)

However, a week later, this option was no longer the focus of the Committee because they opted for an approach that had more flexibility in terms of suppliers and time. Still in-line with what the Procurement Head mentioned above about supplier restrictions, it was eventually decided to do an open tender (i.e. no framework was used) for the purchase of the print software as they did not want to limit the suppliers being invited to participate in the tender process. Another reason that led them to decide on an open tender was due to time restrictions. As the expected value of the print software contract was below the threshold required to be purchased through an EU procurement framework (such as NPA), they had the option to do otherwise. Being a non-EU framework, they had more flexibility with setting the critical timelines, such as the response time from suppliers. When the Project Manager asked whether they could reduce the time between releasing the ITT and getting the response back from the suppliers, the Procurement Head commented:

“Since it’s a non-EU framework, we can do what we want. We can do it to 2 weeks. Usually they complain if it’s less than 3 weeks…so I think 3 would probably be OK. And then we’ve got to shortlist and invite them for a demo, there’s a bit of a gap as well”

(Procurement Head – WC meeting 16)

Create ITT

In creating the ITT document, the Committee had several options for how they accomplished this. The first was to complete it independently within the Committee, the second was to gather partial input from third parties, such as Consultants, and the last was to obtain insight by visiting other organisations in a similar setting to PublicCo to see how they managed their print software.

By the second Board meeting, the purchasing of the print software had not progressed much, meaning it was delayed. This was due to the key person being occupied with other work making him unable to provide input in order for them to make vital decisions. However, the Procurement Head challenged this reason saying that it was more than just relying on the Technical Head. They

137

had other ongoing issues and thus suggested waiting for the Consultants to be on-board to get a second opinion. The option of obtaining third party input meant that the preparation of the ITT was no longer an independent, internal activity, which would be the conventional way of doing things.

Project Manager: The one thing we haven’t made quite so much progress on is the print software. And that’s for a couple of reasons really, [Technical Head’s] availability has not been great before Christmas, he has always said that he would have greater availability after Christmas, so we expected that

Procurement Head: I think it’s more than that, because we haven’t really decided that…we weren’t really sure how to get to the bottom of it, so we thought why don’t we wait for the [Consultants] on it. We can use that expert knowledge to give us another opinion on it because we’ve got different opinions in the group if that makes sense

(Board meeting 2)

Besides relying on the Consultants to assist the ITT document preparation, it was also suggested that a site visit to various software suppliers or users be arranged. This was so that the Committee could gather more information in order to better strategize how they should complete the ITT e.g. what sort of requirements should be included.

“Well I think if we could schedule the [SoftwareS] visit, the [SoftwareP] visit, and then we could have a look at the feature-set of [SoftwareE]…I suspect after that we will have a decision on what we would want to do, and then it’s more a case of finding the best route to procurement”

(Technical Head – WC meeting 13)

Accept ITT

For the approval of the ITT before it was released, the initial option was to only involve the Committee members, but the eventual option was to include the Board members also.

When it came to the approval of the ITT document, in usual circumstances, it would only need the Committee’s sign-off before it is released to the suppliers. However, one of the Board members challenged this approval process and suggested that the Board should give the final approval. Thus this option was chosen as the approval process.

138

“Is it because that we’re the project board, we sort of sign off on the specifications that we don’t sign off on who the final decision tendering is? It’s a procedural issue as to whether, we as the project board, we sign up to the specifications and we’re happy with that…and now we just leave it to the project team to decide?”

(R&D representative – Board meeting 4)

Evaluation period

For the evaluation, there were two parts. One was the supplier presentation, which saw different options for the format of the presentation (i.e. conventional, demonstration style), and the other was the tender scoring criteria, which saw some debate on the various criteria options (i.e. support weighting, financial weighting, technical capabilities).

Once the responses were received, part of the evaluation was to conduct an interview session with the shortlisted suppliers. For this particular sourcing exercise, there was specific interest in the format of the interviews as this involved a technical product and some of the interview panel may have found it difficult to grasp its capabilities. It was anticipated that if they did not have a specific format, the suppliers’ presentation may diverge from its main purpose, and thus not achieve what the project members intended to find out from the interview sessions.

"But we also need to make sure that we have a program of what we want…because if not they would just take us through things that they are interested in. We need to be quite prescriptive, that’s the word"

(Project Manager – WC meeting 16)

One other issue that came up was on the evaluation criteria as questioned by the Technical Head below:

“Remember the interviews [demonstration presentation] are only to inform the questions on the sheets [tender response] one way or the other, at the moment…we’ve already got a winner [i.e. SupplierI]. Now the only thing that could happen is if they dig themselves a big hole, and even if that support line came back as zero, is it going to change the whole score enough?”

(Technical Head – Software evaluation part 1)

The Technical Head anticipated that the support criteria would contribute little weighting if any. Because of this, he believed that the scores after the interview sessions even if they were altered, would not impact the final chosen supplier. This option, however, was not officially agreed on because during a discussion after the presentations, the Committee debated on how they should

139

review or finalise the scores. The Procurement Head posed a question, this time concerning the weighting of the pricing:

“I think if I’m honest, it’s not going to come down to pricing is it? So I’m not sure if doing that [requesting for different maintenance costs]…is going to be much of a difference”

(Procurement Head – Debrief after software demonstration)

Following the software demonstrations, the Technical Head and Project Manager had another round of reviewing the scores based on what they had sat through. During their discussion, it became obvious that the differences between SoftwareP and SoftwareS were very little making it difficult to evaluate which was the better of the two. The following is a discussion between the two Committee members about how they evaluated the two suppliers based on the capabilities of both. Their discussion focused on comparing their technical capabilities, which, according to the Technical Head, do not seem to differ much. However, the Project Manager pointed out a key feature of page type detection that SoftwareP had over SoftwareS.

Project Manager: Like, it was easier for me, I found it much easier to assess what they had gone through and what they hadn’t

Technical Head: Okay, well let’s see if I can put in any... Project Manager: But you’ve got the knowledge of...

Technical Head: Yes, well I’ve used both, so technically, technically I can’t split... I could split on fine grain bits and pieces. These guys have now got the reverse counting in, which is one of the things [Pcounter], who allegedly, I’ve never seen it work, but these guys do have that, that guaranteed page device. They have a better refund model

Project Manager: Right, because that was one of their big differences, wasn’t it? Being able to detect the type of page. So how does that manifest itself in real life? Try and find a scenario

Technical Head: What they really do is if you have got a printer in the library that’s run out of paper halfway through a job, then the job’s been submitted, but the job will, sort of, time out at the end of it, so normally you charge because the job went to the device. I should say, a power cut’s the easy one to go with here. So you submit a job, job fires off, it’s 100 pages long, it gets 10 pages...

140

Technical Head: You’ve charged 100 pages, whereas what these guys are saying is they read pre and post the job...

Project Manager: With these guys, you had to tick the box, didn’t you, to get it to charge post?

Technical Head: Yes, I’ve never seen it do it, but yes, I mean, it could do. I’ve never seen it do it

Project Manager: Because they did say you can do it. We didn’t really talk about it much, but they did mention it a couple of times

(Print software final tender evaluation meeting)

From this conversation alone, it was evident that the foremost criterion that the Committee was looking for, was the technical abilities of the software and supplier. This included technicalities to the very last detail as brought up by the Technical Head above. The rest of the evaluation session continued to be a debate regarding the differences between the software’s capabilities. Eventually, SoftwareP was chosen as the preferred software as it appeared superior compared to the others in terms of what it can offer and its compatibility with the organisation’s processes.

5.3.3 The outcome

From the narratives, it can be observed that options explicitly emerge for five of the sourcing activities as illustrated in Figure 5.3. Firstly, for the selection of the procurement framework, initially the option to use the NPA framework emerged through suggestions based on their judgement that it would provide better flexibility in terms of choice of suppliers. Thus it would provide the best guide for this sourcing exercise. However, the project team opted for an open tender as it also provides flexibility in terms of time, which was an important factor for the Print Project. Secondly, the option to obtain third party (i.e. Consultants’) input for the preparation of the ITT document emerged as one of the Committee members challenged the sole reliance on another Committee member. A third party’s input was assumed to be more impartial and thus provide better accountability for the ITT document. Besides that, the suggestion to go for site visits as part of the initiatives to finalise the ITT came about as it was assumed that the visits would provide more information and thus, more guidance on what to include in the document.

141

Thirdly, on the ITT approvals, the option to involve the whole Board as part of the final review emerged as one of the Board members challenged the original process. Fourthly, since the sourcing activity was for a complex technical product, the option to have a demonstration style interview session emerged as it was anticipated that a conventional presentation would not get its message across to the interview panel. A demonstration approach would provide a more effective guide for the suppliers to prepare their presentation. Thus, there were several options that arose in terms of the evaluation criteria. However, the final decision was chosen based on the supplier’s technical abilities, which at the time of the discussion were deemed as the most important criteria.

Figure 5.3 – Options that emerge during the print software sourcing routine

All these options arose during routine enactment through many deliberative actions, such as making suggestions, posing challenges, and through anticipation. In addition they were also a way of legitimising the actions of the routine actors through referring, guiding, and accounting. For instance, similar to the previous routine, the option to proceed with an open tender for the sourcing of print software was specific to this context. Although it was the same as for the print specialists, the reason behind it was different. The open tender was opted for because it offered more freedom in terms of timescales (e.g. tender response time), providing legitimacy by referring to a specific context of the routine enactment. For the tender scoring activity, all the options that emerged were

142

also specific to this particular sourcing exercise. For instance, technical capabilities refer to the software’s capabilities, support weighting refers to the technical support of the software supplier, and financial weighting in this case bore less importance because it involved a technical product. Thus these options only refer to this particular context.

Routine

activities Options Evidence

Legitimation mechanism Framework NPA "And my concern is that we don’t go down a route that restricts a

list of manufacturers, have to make sure that they all support anybody on the [NPA] framework. So that’s sort of deciding we’re using the [NPA] framework"

Guiding

Open tender "Since it’s a non-EU framework [i.e. open tender], we can do what we want. We can do it to 2 weeks. Usually they complain if it’s less than 3 weeks…so I think 3 would probably be OK"

Referring

ITT preparation

Independent Conventional option Partial 3rd party

input

"I think it’s more than that, because we haven’t really decided that…we weren’t really sure how to get to the bottom of it, so we thought why don’t we wait for the [Consultants] on it. We can use that expert knowledge to give us another opinion on it because we’ve got different opinions in the group if that makes sense"

Accounting

Site visits "Well I think if we could schedule the [SoftwareS] visit, the [SoftwareP] visit, and then we could have a look at the feature-set of [SoftwareE]…I suspect after that we will have a decision on what we would want to do, and then it’s more a case of finding the best route to procurement"

Guiding

ITT approvals

WC members Conventional option

Board members “Is it because that we’re the project board, we sort of sign off on the specifications that we don’t sign off on who the final decision tendering is? It’s a procedural issue as to whether we