CHAPTER 6 : PERFORMATIVE FLEXIBILITY TO ACCOMMODATE THE
6.2.3 Decoupling activities
For the sourcing of print software, a combination of triggers led to two obvious conclusions regarding the intended outcome from this sourcing routine. Firstly, was to cast aside SoftwareS, and secondly, was to proceed with SoftwareP as the preferred supplier.
Disengaged decoupling
Two decoupling activities that were disengaged from the main routine activities were building the proof of concept (POC) model using SoftwareP, and arranging a site visit to SoftwareP only.
One of the indicators that decoupling was occurring, was that there did not seem to be any valid problem with SoftwareS. When questioned by the Consultant, the Technical Head simply
167
said that he wanted a change from SoftwareS. In other words, his preference would be to have any software other than SoftwareS.
Consultant: Are there issues with [SoftwareS]? Is that why you’re looking for…
Project Manager: There are two systems at the moment, [SoftwareO] thing, which is our internal software…and then we’ve got [SoftwareS], which is through [SupplierD]. I’ll let [Technical head] explain
Technical Head: To be honest, I mean it’s a lovely product, showing a bit longer in the tooth really. And it doesn’t have all the features in the modern popular…I’m sorry I haven’t read the report. But it would be interesting to see how the [staff survey] came back. But the [staff] population have been screaming for years in my wish-list about you know…I want to print from my android tablet or print from my mobile phone
(WC meeting 14)
According to the Technical Head, they needed a software product that could cater to the current requirements for the new print management system. To him, SoftwareP seemed to be able to do this although initially some of the Committee members did indirectly suggest that it could be a risk if they decided to proceed with SoftwareP. This was because there were not many other similar organisations to PublicCo that use this product.
Print room Head: I haven’t heard any bad things about [SoftwareP]. […] I think it does what it does
Technical Head: It does exactly what it does! I’m afraid [PublicCo] is very much a…a school of our thought is that we very much always bought stuff that might not be traditionally what people buy. We don’t go out of our way to buy [NetworkS] network because it’s too damn expensive. We take the new kid on the block and that will work
(WC meeting 10)
The above conversation shows both Committee members trying to convince themselves that SoftwareP should be pursued as the preferred software. To convince them further, the Project Manager suggested to have a POC built so that they could see the interface between the software and hardware.
168
Project Manager: I was thinking if you buy the software, you get it in early on, you can then actually start building the interfaces
Technical Head: This is where I wanted to be, I think the right thing to do coming back to all of this is to go and see [SoftwareP] in the flesh for you as a user to see it and say, “that would provide me with features I would want as a member of this [organisation]” […] And then we’ll go away and you’ll turn around and say, “That’s great, I want that feature, I want that, not worried about that…”, then we can go away and shape it. The best example to see that with, is actually [SoftwareP] because it has all the features, so you can turn around and say, “Yes, yes, yes, no…maybe depending on cost”, and then we sit there and go, there’s the list of options, we put that in the tender document
(WC meeting 11)
The Project Manager constantly pushed to move quickly with the purchase of the print software in order for this POC to be built. The intent of the POC was to fix any potential problems with the interface, and address any possible issues prior to the actual roll-out of the new print service in the summer. However the push for the software to be purchased quickly indirectly encouraged the Committee members to focus their energy on obtaining SoftwareP.
“Which is one of the reasons why I’m keen to get this print management software in the bag really. That’s why I’m pushing to get that in quickly now because I think once that’s in, that gives [the Technical Head] opportunity to set the proof of concept, test it, get it integrated with all the various things…he has to do that. And actually to get the infrastructure in place in principle, so that when we get the devices [i.e. the print hardware], it is just a case of [implementing it]. I don’t want to be complacent but at least we’ve done a lot of work for testing, and the sooner we can get on with that…because I’m aware that that would be a bottleneck if we leave that too late”
(Project Manager – Board meeting 3)
Because the final purchase of the software appeared to take longer than what the Project Manager expected, he and the Technical Head decided to move ahead building the POC using a trial version of SoftwareP. In the following Board meeting, the Project Manager acknowledged that going forward with this approach had its risks. One of the main risks was that SoftwareP may not turn out to be the chosen software at the end of the sourcing exercise. However, if looking at a different angle, by having a POC that shows the successful interface using SoftwareP, it would definitely have some influence on the views of the other Committee and Board members with regards to the software.
169
“I’ve asked [the Technical Head] to produce a proof of concept on one of the platforms that we’ve got, and he has done some work to try to understand what’s involved in implementing that particular solution. It was a risk because it might not have won the tender, but [the Technical Head’s] going to be able to demonstrate that on the 24th March [2015]”
(Project Manager – Board meeting 4)
Besides having a POC, another activity that signified SoftwareP as the preferred supplier throughout the sourcing process was the site visit. Initially, a site visit for SoftwareE was planned out as seen in the conversation below:
Print room Head: Yup, I’ve had some responses back from [various companies] …they’re all competing for us to go! Depends how far you want to go. The ones that have come back, there’s [ChestCo]…
Project Manager: What are they? Are they [SoftwareE]?
Print room Head: Yup, [SoftwareE]…they’re all [SoftwareE] because that’s what he [Technical head] wants to see. There’s [SouthCo], which is a way to go […] and then the last one that came through this morning is [StockCo], which is a good one, because it’s a big one…they’ve got a lot of devices there. I say it’ll be interesting because that [organisation] used to be a [SupplierD]…it was a [SupplierP]…they lost it on price to I don’t remember who it was, but it is [SoftwareE] anyway. So I would suggest that in terms of size, compatibility, [StockCo] would be a good one.
Project Manager: What about [SoftwareP] though? Because we talked about [SoftwareP]
Print room Head: Well do you want [SoftwareP]? Well I can do the same exercise. So now we have a [SoftwareE] site that we’re happy [with]….so so now [SoftwareP] people will have a chance to offer us green tea...or whatever else
(WC meeting 9)
From this conversation, it was as if SoftwareE was the initial software that the Committee thought would be ideal for this project since it had been proven successful in other similar organisations. A few meetings later, the plan was changed slightly to include visits to different organisations for all three software products i.e. SoftwareS, SoftwareP, and SoftwareE to compare their capabilities. The Technical Head suggests that by seeing all three, the Committee would have
170
a clearer understanding of what they would like to set for their software specifications that are to be included in the ITT.
However, eventually a site visit was arranged only to view SoftwareP for two reasons: (1) it was the Technical Head’s preferred software, and (2) the organisation they visited (i.e. ShefCo) had purchased their software separately from their print hardware, which was the approach PublicCo wanted to adopt. The idea was to gain insight into the advantages and disadvantages of SoftwareP based on feedback from ShefCo. This insight would then either help to confirm or disprove their current views regarding the software’s capabilities. During the visit, there was one negative insight about SoftwareP and its supplier (SupplierI) that was related to the support service as seen in the statement below:
“The basics…they’re fine. Then past them…if there’s anything more in-depth, as soon as you get to [SoftwareP], they’re brilliant, but the [SupplierI] support team aren’t. Product is great, the support…the basic stuff in setting and configuring and all that kind of thing, is fine…but anything deeper...”
ShefCo representative – PublicCo’s site visit
However, even with this input, the site visit did not change the Committee’s view that SoftwareP was ideal as the preferred software. During the journey back from ShefCo, they had a discussion on how not to make it too obvious that they preferred SupplierP over others.
Project Manager: You can’t just say, “right, we’ve decided…we’re going to buy [SoftwareP]” can we?
Technical Head: That’s why their points were quite interesting…welcome to the world of tendering! You want it to be competitive enough, so that you get more than one response. Because there’s no point writing a tender that’s just [SoftwareP]…
Project Manager: Yeah, need to be fair
Technical Head: So there’s a fine line that need to be drawn between the two (Informal discussion returning from site visit)
Engaged decoupling
There were several decoupled activities that were part of the official routine activities. These include being biased during tender scoring, and demonstrating favouritism during supplier interviews.
171
By preparing a more generic ITT, the Committee received several responses that offered different solutions. There was SupplierI who offered SoftwareP, and then there were SupplierB and SupplierT who both offered SoftwareS as the solution in their proposal. While comparing evaluation scores for SupplierI’s proposal, there were several instances where the evaluators demonstrated a form of bias in their marks. The following conversation was one example:
Technical Head: 7B, what’s that? Please describe…something (laughs) Project Manager: Ooo…this is the device management thingy isn’t it? Technical Head: [SoftwareP] does do this, doesn’t it?
Project Manager: It does…to a degree obviously
Technical Head: I mean it’s not as good as [SoftwareJ]
Project Manager: Yeah, I know…the thing is they’re quite lazy. I mean look at the detail
Technical Head: That’s where I’m coming from…you gave it a four
Project Manager: A four? Did I? Maybe they needed a crack at the answer even though they have the capability. [He reads back his comments] I think it was a bit shit…I mean email? I thought…whereas [SupplierD], which supposedly can do less said they can actually put things on the console itself, not email!
Technical Head: We’re going to compromise on a six
(Software evaluation part 1)
In the above conversation, the Project Manager had initially marked a particular section with a very low score. But when he tried to explain why he gave SupplierI such a low mark for it, the Technical Head immediately cuts him off and puts down a higher score instead without much justification. Another example is shown in the next conversation:
Technical Head: So the last one of the list, is the [SupplierI] one…see I’ve given a 10, look at that!
Project Manager: You’ve given a 10? Now who’s being generous? Technical Head: To be honest I was thinking it was a super answer
Project Manager: What was that? Which one was it? The first one by the looks of it
172
Project Manager: You were immediately impressed and entered the blocks weren’t you?
Technical Head: I was sold…question 1, solution works in our environment! So, yes! Sorry…I’m not going to change it
(Software evaluation part 1)
While the first example illustrates a scenario where a low score was increased, in this scenario the Technical Head provided a very high (perfect) score for one of the sections. Even when the Project Manager questioned the mark given, the Technical Head did not change his score. At the end of this evaluation session, the Project Manager raised a concern that they had rushed with this activity, but then seemed to convince himself otherwise:
“I’m just slightly worried because we are rushing this as well…we might not be able to check our working out, then we can easily make a mistake and that could be a bit embarrassing couldn’t it?... And we’ve got all three in, if we invite all three in…then we’re covering our [backs]”
(Project Manager – Software evaluation part 1)
After the scoring activity, all three suppliers were invited for an interview session, which was held as a demonstration format. But because SupplierB and SupplierT offered the exact same solution, they were invited to the interview as a joint session. Therefore in effect, there were only two software demonstrations that the Committee had to attend. Before the demonstrations, the Technical Head reminded everyone that this activity should not affect the supplier scores. According to him, the interviews were only to “inform the questions on the sheets [i.e. tender responses]”, and not add any new information that could increase the supplier’s scores. Thus
indirectly, making sure that SupplierI (which proposes SoftwareP as the product solution) would become the winning supplier.
During the interviews, again there were some instances where favouritism was quite obvious. For instance, during SupplierI’s interview, when one attendee kept on repeating his question to the supplier representatives to get the answer that he needed, the Technical Head jumped in and provided a clearer answer to the question. This act demonstrates that he wanted to help SupplierI by not letting them look bad in front of the other project members.
IT representative 1: Sorry I’m not making myself very clear here, I apologise for that. If I have all these options, can I set a default where you can just go in and click ‘yes’ and moving on, rather than
173
having to walk through all my options if I don’t want to walk through it all
[SupplierI 1 and SupplierI 2 continue to provide a solution for this, but they seem to struggle with a convincing answer]
Technical Head: I think to bring this forward, if you know the average Joe [staff], or Joe department member and go through [IT], you hit print jobs…it flies through the system […] so there’s pull- print, drop, go…three button clicks. So that’s the average Joe…the other step then is on the 3rd click, which has the option of which cost code to take, so you’re looking at four to five clicks. I can’t get you away from that
(SupplierI interview)
In another example, this time during the other interview headed by SupplierT, when the representative attempted to answer the question given by an attendee, the Technical Head came up with a sarcastic remark in response. By doing this, indirectly he was trying to make SupplierT appear incapable in front of the other project members, thus giving them a disadvantage.
Procurement Head: Nothing specific, I guess you probably already answered it, it’s just a general point about…everything that you’ve showed us today is included in the pricing…the things that you’ve mentioned and the client billing and all that. So that’s just my general point, is that it’s all included?
SupplierT: Oh yeah, everything that I’ve shown on the screen
Technical Head: One other quick thing is…
Procurement Head: Do you have any specifics on the numbers?
Project Manager: No I don’t think I have
Technical Head: Yeah, well [SupplierT] have a history of getting this right…so it’s all good…(sarcastically)
SupplierT: No problem
Technical Head: No no no…honestly! (laughs)
(SupplierT interview)
In a proper sourcing process, a supplier is chosen based on cost as well as quality. However, in this case as pointed out by the Procurement Head, the cost held no influence in the final outcome but was down to the quality scores, which in this case was won by SupplierI. In the journey to achieving the intended outcome of removing SoftwareS and obtaining SoftwareP, the project
174
members took part in many activities that would be considered out of the norms for a sourcing routine. These activities included: building a POC using SoftwareP, arranging a site visit to SoftwareP only, providing biased scores for SupplierI, and showing favouritism during supplier interviews.
6.2.4 Summary
Table 6.2 provides a summary of all the triggers, targeted outcomes, and decoupled activities within the software sourcing routine. A combination of unsatisfactory experiences and uncertainties regarding the capabilities of certain software steered the Committee to deciding that they should remove SoftwareS from the picture, and focus on SoftwareP as the preferred software. Since the decision between SoftwareS and SoftwareP was based on the proposals, it was clear to see that the advantage lay with SoftwareP as, since the beginning of the project, it was presumed that SoftwareS was not capable enough. Thus, the preference for SoftwareP was obvious through the many actions whether deliberate or not, that led to decoupled activities.
Endogenous sources for establishing targeted outcomes
ostensively
Targeted outcome accomplish targeted outcome in Novel actions via decoupling to routine performance Past experience:
Undesirable experience with
SupplierD’s service and its software i.e. SoftwareS
Different expectations in
deadlines
Perceived uncertainties:
Uncertainties with the future
developments of SoftwareS and SoftwareE
Concerns about how time is
managed
Remove SoftwareS
SoftwareP as preferred software
Disengaged decoupling:
Build a POC using SoftwareP
Arrange a site visit to
SoftwareP only Engaged decoupling:
Provide biased scores for
SupplierI
Showing favouritism during
supplier interviews
o Assist SupplierI with
interview questions
o Being harsh with
SupplierT
Table 6.2 – Summary of decoupling sources and activities to accomplish the targeted software supplier
175