ISDM Selection
introductory comments
Information system development (ISD) projects fail too often. There have been efforts to solve this problem for decades, but the success rate of ISD projects, nevertheless, remains low. One reason for this is that a wrong ISD method (ISDM) is used in a particular kind of ISD project. When client organizations and supplier organizations have different kind of business objectives for an ISD project, they have different perspectives for the ISDM selection, as well. Because the client organization is the final user of the developed IS and the final evaluator for the achieved business benefits, the client organization’s perspective is of emphasis here.
When the reasons for failures are discussed, it is important to consider what a failure, or a success of an IS project really means. The traditional project management success criteria are budget, schedule and scope. This trinity is often called the project triangle (or iron triangle) and it is used as a project management tool. Also, if one of these three is changed, one or both of the two others have to be changed, as well. However, as said, these three criteria are only project performance criteria; they do not take into account the business benefits pursued by a project. There are examples where projects have remarkably exceeded their budget and schedule, but, later, the developed product is found to be very beneficial. So, the failure percentages based on the project management success criteria is not the whole truth, and project success should be measured more in terms of business perspective and during a longer period of time after project is finished, but we may assume that these percentages still offer indicative information.
My major criticism of enterprise PMOs is that they are proponents of the one-method-for-all-projects approach, dubbed as the “universal approach”. You work for SAP then you follow its method, no matter what the project. You work for IBM then you follow its method, no matter what the project... ad absurdum... The problem with this approach is that all projects are considered to be similar to each other, which they are not. Projects differ from each other, and, more importantly, organizations differ from each other. If you have followed the argument till now, then I hope you will see that it makes to state the following -
To get better suited ISDMs to ISD projects, ISDMs should be selected for a project case by case. The characteristics of the selected IS development methods should match with the characteristics of the business development context where they are used. Nowadays, when the majority of ISD projects are more or less outsourced, there are normally two parties involved in IS development: a client (i.e. customer/buyer/acquirer organization) and a supplier (i.e. vendor/contractor/seller/developer organization). The business objectives of an ISD project drive the client’s behavior, while the ISD project is the business opportunity in itself for the supplier.
From the supplier’s point of view, the traditional project management success criteria, time, money and scope, are preferred for project success criteria, while effectiveness, business satisfaction and the use of the IS are more important criteria for the client.
The straightforwrad conclusion is therefore that the client organization should have the main responsibility for the ISDM selection for a project. In addition, the timing is important because IS development is done according to the contracts and MSAs are made before the ISD project is started. Those contracts define or at least give a frame for a possible ISDM for a project.
The decisions made before contracts are signed are important; with wrong decisions, a project will be doomed even before it is started. This is why it is becoming more and more important (and prevalent in the savvy organizations) to have Client Partners involved with the Delivery team in the Sales Cycle.
This is what is termed as Shift-Left of the delivery organization. One can generalize this principle and say that any phase of an innovation project which is involved with its predecessor phase, regardless of having crossed the OPP in the social worlds through the Boundary Object that acts as a bridge between them, will benefit from this foresight. For example, handover to the client care or customer success team or operations team, at the project closure, is also shift to the left so that the transition is smoother and better decisions are taken.
So my main point stands that the ISDM selection should be done right after the main requirements are analyzed, before a supplier is selected and contracts are made. Think of ISD, ISDM, Vendor and Client as the four prinipal actors, with the organizational sales cycle, contracts and the different objectives of the organizations as the secondary actors. As you can may have notices while reading the above, I was tacitly doing a controversy analysis but without defining the programme. In essence, the underlying programme was not explicitly alluded to though highly implied. The principal programme, is in my view, how to choose the right method for the right project. In innovative situations, an inference from the above is that the traditional trinity of Scope, Schedule, Budget ought to go out the window. Which as we will see, is the underlying innuendo behind Value Chains and Customer Journeys.
Success and Failures
In this section I am going to focus attention on answering the question - How should an ISDM be selected for an ISD project? This question flows naturally from the previous section, in which I have given you the generalized tools to think about innovation management. I am going to assume that I will not have to elaborate too much on specifities of the methods in vogue today. As much as possible, I will keep the discussion as generalized.
It is difficult to answer the question which has been posed above. An approach would be to use the MECE (Mutually Exclusive, Collectively Exhaustive) principle. So I will try to break the question into parts and sub-parts, and then concentrate on trying to answer them to come to a conclusion at the end of the section.
What can be said about the matching ISDMs and the characteristics of business contexts where they are used based on the analyses of failed ISD projects (ex post)?
What business contexts, and/or other novel reasons for failure were related to the failure of the projects?
What kinds of ISDM selection models and criteria are possible to find in the literature, and how well do they account for the characteristics of business contexts?
Is the framework able to capture the results of the prior ISD method selection research?
Would the ISDM professionals consider the ISDM selection framework useful for ISDM selections at the project level?
What other criteria could be considered and how should they be taken into account in the framework for innovation projects?How common is it for the client and supplier organizations dealing with innovation projects to conduct systematic, project-specific ISDM selections?
What are the main reasons for client and supplier organizations to conduct or not conduct systematic, project specific ISDM selections?
In the ISDM selection decision-making, is it possible to describe the behavior of the ISD projects’ client and supplier organizations with bounded rationality and functional stupidity theories?
Project Success
The industry has bought the idea that a project is successful if it is completed on-time and on-budget, with all features and functions as initially specified. I have not, and I will proceed to give my reasons. Although, scientifically speaking, it is irrational that I have to explain my reasons, given that the burden of proof should be on the people who proposed the triangle, and not on me to refute their claim. However, in the context of ANT and controversy analysis, it is reasonable for me to try to enroll you in my programme, and it is healthy for me to have the strong opposition of the generally accepted success definition because it means that my anti-programme is going to make you think! And if not completely, then at least partially, will allow you to come up with a Black Box approach of your own.
It is important to separate project success and project management success. Project performance metrics, however, are insufficient to capture project value, such as business benefits. Good project management can contribute towards project success, but is unlikely to be able to prevent project failure. Project performance metrics are important but secondary to, or part of, business benefits.
However, measuring business benefits is possible only some time after a project has been completed. A reliable measurement is difficult due to the delay between a development and its benefits realization, as well as due to intervening factors such as changes in the inner and outer business circumstances. Do you see where I am going with this? Endogenous and Exogenous networks being influenced by non-human Actors who after having ratified Boundary Objects may deem the deliverables to be futile in the oncoming phases after the project is completed. Suppliers are seldom able to influence the business benefits realization with their actions. Hence, suppliers are reluctant to accept clients’ business value metrics into ISD project contracts even though they usually regard client satisfaction as an important factor of an ISD project. Because of this, there are examples of poorly performing projects that were later praised due to high business value creation. Clearly, this means that in order to proceed towards innovation management, we need to encapsulate success in an ameliorated definition. A lot of thought has gone into this already by business leaders, so I will simply paraphrase the ideas with which I resonated the most. To cover the various perspectives of project success, we may consider six project success areas. The first three cover project performance: time, cost and the delivery of agreed-upon outputs. The other three address project value, satisfaction and effectiveness for clients and user organization.
In order for a project to be considered a success, it should be successful at the four levels shown in the figure above. It should also be mentioned that the mirror image should also hold true so that failure can be properly defined. And both should be pondered together to come up with the evaluation techniques suited for that specific project.
Changes in one project may also affect the other projects (e.g., when resources are limited), and project portfolio management is needed to prioritize the objectives and to allocate resources of individual projects. Project management methods like PMBOK and PRINCE2 are mostly based on the stage-gate model, meaning that the project has gates that can be passed when all the previous stage activities are done and all the necessary results achieved. The gates are used as project checkpoints (sometimes coinciding with milestones), and the project is re-evaluated in these gates: whether the project should continue as planned, whether it should be changed or whether it should be cancelled. If the stage-gate model is strictly followed in an ISD project, it has a tendency to change into a waterfall style of development. Which is why it has always made sigh when I saw self-proclaimed Agile PMOs instituting the phase-gate model. I will get to this contradiction in a while, which in essence is precisely the problem we are trying to solve by choosing the right method for the specific project in question.
The requirements are often the only discussion media between ongoing business development and IS development. Using the requirements as an integration tool is very challenging, and problems in requirements management are reported as one of the most significant causes of project failures. Furthermore, many of the problems in requirements management seem to be caused by problems in communication. In other words, business people and IS developers do not speak “the same language,” if they speak to each other at all. The requirements used to integrate the different development projects are normally not as thorough as they should be, nor are they centrally managed, organized or well-coordinated. When requirements are elicited and a development project is started, the problem is how to manage requirements during the project. Changes still happen quite often. In the waterfall type of development, this is a problem. Changes have to be discussed in a steering meeting, and they always cause the project to be replanned. Because re-planning is time and resource-consuming, requirements are not changed easily.
I also want to point out that between Vendors and Clients the contracts are often Fixed Fee, due to many reasons. These reasons may be out of the project's control in the organization, and may very well be the result of how Accounting and Finance are done. This Fixed Fee type of contract leads directly to a Waterfall-esque ISDM which is based on Phases and Gates. I have been a huge proponent of projectized organizations, especially when dealing with consulting firms. Thus far, I don't think I've had a huge success in changing how contracts are made at the generalized enterprise level, but I claim a modicum of success in instilling this scrutinization discipline at the PMO level.
In this environment, one can see how attaining Project Success may be a little bit difficult :-) Because neither do we define success properly, nor do we know choose the right methods, and furthermore there is an incipient breakdown of communication between vendors and clients because they are often speaking cross purposes. Isn't this exciting! Think back to the pathologies of innovation projects, and you can connect the dots between waterfall and ballistic projects.
innovation failures
I want to choose the double diamond model for innovation, before talking about how and when does innovation fail. The first diamond in the model represents the problem space for the innovation process. During this diamond’s divergent phase (i.e., left half), innovation involves discovering problems that motivate and guide the innovation project. The first diamond’s convergent phase (i.e., the right half) involves gathering, merging, and ‘narrowing down’ the previously identified problems. The convergent phase involves assessing, combining, reducing, and selecting the problems to define the goals of the innovation project. The second diamond in the model represents the solution space. The first phase of this diamond (i.e., the left half) depicts the divergent nature of innovation as generating potential solutions to address the project goals. The innovation team members brainstorm, adapt, share, and iterate on various solutions to address the shopping cart safety, maneuverability, storage, and security problems. The convergent phase of the second diamond (i.e., the right half) is where innovation team members ‘close down’ on promising solutions. They evaluate and test cart design prototypes, refine the solutions, and use the learning and decisions in this phase to converge on and develop a final solution.
Each of these phases has its own specific types of failure. But first let’s define failure. Failure, in general, is defined as a deviation from desired goals. Task failures are not doing the right innovation process tasks with the right people in the right way. This type of failure is an action error in that some deviation from a task-based rule or standard has occurred. Outcome failures are a lack of outcomes or producing and choosing erroneous outcomes within some phase of the process. Outcome failures often result from one or more task failures, but not every task failure results in an outcome failure. Consequently, we define innovation process failure as involving one or more task failures and outcome failures combined within the process to result in a mode of failure that prevents the attainment of expected innovation goals.
The failure value stance is the extent to which individuals in an innovation process attribute value to different innovation failures within the innovation process. Given that innovation failure appears at different divergent-convergent stages throughout the innovation process, the attributions assigned to these failures also differ depending on the process phase. When a positive aspect is attributed to a detected failure, learning from these failures encompasses anticipating them and embracing the opportunity to derive valuable lessons. However, attributing value to failure can be challenging as organizational members tend to attribute success to internal factors like ability and effort, and failure to external factors such as bad luck. Below are the various types of failure.
Anticipation and value of task and outcome failures are more likely in the divergent phases of the innovation process.
Anticipation and value of task and outcome failures are less likely in the solution space divergent phase than in the problem space divergent phase.
Anticipation and value of task and outcome failures are less likely in the convergent phases of the innovation process.
Anticipation and value of task and outcome failures are less likely in the solution space convergent phase than in the problem space convergent phase.
The above axioms can be seen in the figure below.
Now that we have seen about success, and as well as failure, let us return our focus on how to Project Management for Innovation.
The above figure gives a framework of how to run an project, when there are various actors, divergent and convergent ideas, and principally understands the model of innovation using prototyping. I often run my projects using the ideas explained thus far.
Organizational development
The assumption in most Innovative endeavours is that if a project is thoroughly planned and relevant risks are identified early enough, uncertainties are possible to resolve with project management and risk management during a project. Inadvertently though as it may be, such assumptions because silent non-human anti-programme actors which act against the interests of the business benefits (which commissions the project at the client side).
Although the planning approach is rather generally applied, especially in mechanical engineering, it should be noted that comprehensive planning is not possible in all development situations. In some cases, organizations are not willing or capable of doing comprehensive requirements gathering and project planning, but there are cases where all relating uncertainties or an optimal solution are not possible to see beforehand, even if desired. It is idiotic to assume that business success looks like right from the inception phase of an innovation. How can this assumption be true, if we are in a forest of actors, where there is no controversy line, where there is already black box, and there is a consensus in the community of where most claims lie on the fact to fiction continuum? In Innovation initiatives, traditional comprehensive planning before development is not possible, so the problem will be thoroughly understood only as a solution is developed.
Before one can execute an innovation development, the idea itself has to come into existence somehow. This phase when the ontological/fictional realm is ongoing and the overall discussion is still between the actors who have not yet had to undertake the trails of strength nor the tribunals of reason which come into affect during/after the reification of the concept's first iteration, is very important to understand. Based on their uncertainties, opportunities or candidates for innovation can be classified into three types -
Opportunity recognition, not much development is needed; the idea is that both sources of supply and demand already exist and the only task is bringing them together.
Opportunity discovery, only either demand or supply exists and the non-existent side has to be discovered (and/or developed)
Opportunity creation, neither demand nor supply exists and they have to be created.
In organizations with a strong traditional project culture, it is not so obvious that the nature of uncertainties relating to opportunity creation is fully recognized in the project planning phase. I hope you can see why.
It follows that innovative organizations should allow for opportunity creation, and that it should be outside of the scope of the traditional PMO. There are many different types of PMOs as well, and I will get to that later. We will have to think about which PMO type ought one to prefer, if one wants to have opportunity creating innovative projects not hampered by the endless controls that a traditional project culture instills.
It may amuse you to know that a Sr Manager of Innovation at a fortune 10 company, once went a 45 minute rant against their own PMO with 300 people on the conference call. I had to calm him down later on and make some adjustments in the metarules of the innovation programme. You can imagine that this is the forefront of the controversy line.
The future situation and its uncertainties are not the only critical issues to be considered; the current situation, such as the business context of development and its uncertainties, is also important. When discussing systems development, most of the effort is often put toward the solution domain, and the current situation is neglected. If the uncertainties of a current situation are not taken into account, it means that only the desired end state (to-be situation) is discussed, and the starting point (as-is situation), e.g., the maturity of the business process to be developed, is neglected.
This leads us to the fascinating subject of Gap Analysis. This activity is usually undertaken by the Supplier/Vendor so that they can get a clear picture prior to implementation of an IS at the Client side, regarding what the product (or the idea of the future state of the product) is capable of and how that helps the clients situation hypothetically in the future by making them move away from the current situation, which is abjured and repudiated as being something worth guarding. But again, this is what I meant above when I said that the client and the vendor are speaking cross purposes. The client should be speaking about the business benefits that are realizable (which may come in part from improvement of business processes or their efficiency), whereas the vendor wants to concentrate on the product and its features with a tacit disregard for the organization (even during the To-Be vs As-Is talks).
This is what is fondly referred to as the “We Are Not McKinsey” argument by most tech firms. The idea being that if you want strategy advice and organization building advice, then hire consultants. For we only do the software.
What an utter admittance of defeat by supposedly the best scientifically innovative brains! What they miss here is that in Industry 4.0 all tech firms are de-facto strategy firms. Otherwise, the tech firms which won't guide business strategy of their collaborators and clients will become extinct, by sheer evolutionary pressures.
In the very simple, modest but powerful framework presented in this section, future uncertainties in development are seen as an important but insufficient factor to be considered before the development project is started. Also, uncertainties related to the current business context are taken into account when development projects are started. I could have given you the framework directly, why this dilly dallying around, you may wonder? For you need to know why we are doing what we are doing, and how did we get here.
Also, and perhaps more importantly, we need to learn to be disagreeable if you want to drive innovation. Otherwise you will end up accepting the status-quo. All the above generalized thought experiments show you that wave after wave of managing technology has involved someone somewhere standing up and saying - No, I do not agree. And this brave disagreeable actor was able to enroll the others onto his programme.
When an IS is developed, it always impacts the organizational/business contexts of the development; that is, it supports and/or enables business development. (R)evolving changes and uncertainties related to the changes characterize organizational/business development. Changes in their uncertainties may be related to the execution of business (processes), i.e., current business context, the outcomes of changed business execution, or both. It is necessary to describe how different ISD methods, i.e., plan-driven and change-driven, approach these two types of uncertainties and how organizational development addresses the same issues.
Decision Making at Org Level
The method selection for an innovations project ought to be regarded as an organizational decision-making situation. Which is an issue to be solved in itself, because responsibility is therefore not on one person, but shared amongst a group and a whole section could be devoted to Game Theory and group dynamics. Fortunately, I am not going to do that here. Let alone the aspects to human-nature; there are some key fundamental difficulties with decision-making.
It is impossible to have enough knowledge about the consequences of each choice.
The probabilities of consequences can be only imperfectly anticipated.
It is not possible to detect all the possible choices.
Unclear technology and fluid participation of actors at the initial stages.
Different kinds of decision traps (such as the status-quo trap, the sunk-cost trap and the confirming-evidence trap) characterize decision-making at the individual level.
So even if organizations wanted to, they could not make the perfect decisions. An approach which calls for organizations not to maximize but to satisfy, i.e., look for alternatives that are “good enough” is called Bounded Rationality. It is also possible that bounded rationality may lead organizations to consider ISDM selection decisions as unimportant and/or to misjudge the benefits and costs of ISDMs. A client may also satisfy with the selection of a supplier, for example.
“Organizationally-supported lack of reflectivity, substantive reasoning, and justification” characterize theFunctional Stupidity decisions, which by their definition are clearly harmful in the long-term, although they may or may not be harmful in the short and near term. In this way, organizations protect themselves from “the frictions provoked by doubt and reflection,” which in turn strengthen organizational order and employees’ motivation in the short-term. Consequently, all (rational) discussion about the situation and how it could be improved is neglected (sounds remarkably similar to the way Democracy and Politics work?). So, in the immortal words of Charlie Munger (paraphrasing), try consistently not to be stupid instead of trying to be more intelligent than what your education allows.
So now think of the interaction between a Client and a Vendor in terms of ISDM for innovations. You are looking at all different possible combinations of Functional Stupidity and Bounded Rationality, even before the project has started.
One can imagine a continuum or a scale, with “universal approach” for all ISD projects on the one hand (which axiomatically implies Functional/Organizational Stupidity), and having the “selection approach” on the other hand (which means that no single approach or ISDM is regarded to fit the needs of all projects, and that decision should be taken on a case by case basis).
Two other approaches fall somewhere in the middle of the above-described scale. The “tailoring approach” acknowledges the claim that no single method suits all ISD projects, but on the other hand, it also suggests that some kind of “meta-method” may exist, which could be tailored to every project. This is a refined version of the “universal approach.” On the other hand, the “engineering approach,” which is closer to the “selection approach”, proposes that the most suitable method for an ISD is constructed by selecting suitable fragments from the variety of ISDMs available to an ISD project.
Also, one must not buy into the assumption that every organization indeed has an approach, which ironically is also an approach. It is called the “ad-hoc approach”. Believe me, I have worked with many such organizations… The tales I can tell…
Information System Development Methods
First let's call for verbal hygiene. Method is defined as a particular procedure for accomplishing or approaching something, especially a systematic or established one. Methodology on the other hand is a study of or a system of methods used in a particular area of study or activity. Which is why I prefer the word Method. The term “method” in this study means a process model of how information systems should be developed. As previously mentioned in passing, broadly speaking there are two - Plan Driven and Change Driven.
Plan Driven
Plan Driven Methods assume that it is possible to thoroughly plan every aspect of development work in advance, such as objectives and their metrics, tasks, money and resources needed. In plan-driven life-cycle methods, planning and development are divided into separate phases. Development starts immediately after the planning phase is completed. The best known Plan Driven method is Waterfall, and various companies have some mutation of Waterfall embedded in their PMOs with their own specifics based on their internal Software Life-Cycle.
The assumption regarding the business context is that objectives and deliverables of an IS development project can and should be clearly defined in advance. Consequently, it is also assumed that project tasks and workloads, resources and risks are definable in advance and that most suitable (IS) developers can be allocated to the project since needed capabilities and competences are known. Project and steering group meetings, as well as checkpoints (gates)}, are used to ensure that the project is on the right track. Continuous risk management and mitigation activities are executed to avoid the realization of risks with high probabilities and serious adverse impacts.
As previously mentioned, this is very much not a characteristic of a truly innovative project. Refer back to the pathologies if needed. I won't spend much time explaining what this is, a vast literature exists already... but I will list the main criticisms -
Requirements Management related
Incomplete requirements
Unrealistic expectations
Changing requirements \& specifications
Lack of planning
Need for initial scope redundant
Client issues related
Lack of user involvement
Lack of resources
Lack of executive support
Lack of IT Management
Vendor issues related
PMO - underestimation, resourcing problems (staff added late, inadequate staff, an aggressive schedule)
Communication and involvement problems of stakeholders
Project Management (including risk management), poor change management (including late response to problems) and technology problems
Despite this cascade of problems, PMBOK and Prince2 (and their related credentials), which are considered by the industry as the gold standard of PM certifications are fully aligned with the Plan Driven Approach. Looking at their books, as a practitioner I thought - How wrong it is to teach and advocate that this is the only way how you manage projects well! After repeated criticisms and pushback from practitioners they have recently tried to change, but looking at the new materials I am not convinced that their DNA has altered that much. Though, I do congratulate them for the attempt.
Change Driven
In change-driven development, the idea is that the whole information system is not planned at once, but planning and development are done in small steps, and after each step, the situation is re-evaluated and necessary changes are made to the objectives. Each such loop is called an iteration. You will often hear the term iterative methods almost interchangeably with Change-Driven methods. I prefer the term Change-Driven because you don't necessarily have to iterate to acknowledge that change is needed and to be factored in.
My own professor used to stress on the importance of prototyping. It occurs to me after many years that he was trying to get me to accept change. The industry refers to the above concepts using rather absurd terms like Agile. It's almost as though they are saying that Plan Driven methods are not Agile (in the dictionary meaning of the word), and therefore create a false dichotomy. This has become a marketing gimmick and loads of careers and fortunes have been made by consultants who sell Agile and Agility. The market is booming for certifying authorities who promise to make you an “Iteration Manager”} in 2 days.
The Scrum process is just such an example, see Figure below. In a scrum, the Product Owner (representing stakeholders of the project) discusses the relationship between IS and the business context continuously. The (business) objectives of a project are re-evaluated between each cycle and may change several times during the project. Therefore, it is possible to address uncertainties, both in business execution and in business outcomes. Business related change management actions, for example, the remodelling and improvement of a business process, are left to process owners (including the Scrum Master) and are seen as part of the continuous dialogue between project stakeholders.
Prior research has discovered that change-driven IS development cannot be managed with plan-driven project management methods. Similarly, there are differences between the failure reasons (risk items) of change-driven and plan-driven IS development. Project management challenges, an approach that is too end-user–centric, messy software structures with maintenance difficulties and poor IS architecture compliance are often mentioned as reasons for the failure of agile ISD projects.
I won't spend much time explaining what this is, a vast literature exists already... but I will list the main criticisms -
Future Vision pertaining - Since there are no clear plans or target descriptions, it is unclear what will be delivered at the end of a project and what the costs, resource needs and duration of the development are. The evaluation of quality of results and other outcomes is another unsolved issue.
Technical Debt - Because change-driven development makes it impossible to predefine the architecture and code structure, new increments may introduce new and unpredictable code requirements, leading to software conflicts. Cumulative inner problems of this kind are referred to as technical debt.
Trade-Offs - In general, maximizing agility increases the risk of trade-offs, for example between fast deployment and poor development practices.
Epistemological constraint - Customer-driven IS development projects experience loss of direction unless customers know what they want all the time.
Knowledge holders - The execution of change-driven development projects rests on the availability of highly skilled individuals and their tacit knowledge since formal planning and documentation are limited.
Contracts - The scaling of outcome and contract negotiations have also proved challenging, because a contract is by definition a boundary which includes or excludes goods and services in exchange for payment. How to scale contracts which are making that boundary fuzzy, in terms of scope? An approach was to have T&M contracts, but it has not yet had the wide scale adoption because the onus of what is being delivered falls directly on the client, who may not be the experts in the IS field.
The use of change-driven ISDMs underscores the importance of a client’s ISDM competence in a way that is similar to the backsourcing effect of digitalization. In change-driven ISDMs, the tasks and participation of IS user organizations (clients) are wider and more active than in plan-driven (waterfall) ISDMs. IS user organizations are responsible foruse cases, user stories, user testing and feedback, and they participate daily in the ISD work.
ISDM Selection
It is possible to execute a successful, troubled or totally failed ISD project with any ISDM, and no single ISDM guarantees success for every ISD project. With a situation such as this, it is important that the suitability of different ISDMs should be separately evaluated for each development case, and the most suitable ISDM should be selected for a project. Client and supplier, have different business objectives for a project, and the best possible ISDM for a supplier is not automatically the best choice for a client.
So, there should be discussion about methods on the part of the client well before the ISD project is started. Selecting the right IS development methods for the right projects is challenging. Some guidelines exist, but they are mainly concentrated to project-specific dimensions and parameters. The ISDM selection is not usually considered in terms of the customer’s business.
Unfortunately, not everybody will agree with you if/when you say the above. People seem to be married to their special method regardless of the project they are undertaking. This is where you need to zoom out, and make an ANT based strategy to enroll people to your way of thinking (see previous post). This is going to be half the battle, especially if you are up against executives (or others who outrank you). Once the contract is signed, then all of this discussion goes out the window, so the critical timeline aspect should be impressed upon whomsoever is in charge and an anti-programme actor. A signed contract which puts a boundary based on a specific method, will either make the project or break the project.
Sourcing strategies should be taken into account when thinking about ISDM selection. It has an impact, because it definitely is a degree of freedom (at either the client side or the supplier side). And they can also help in framing the proper contracts for the project. There are 5 main ways of sourcing -
Outsourcing: an IS user organization mandates an IS supplier to develop an IS. Responsibility and risks are moved from IS client to IS supplier.
Insourcing: an IS user organization executes the development of an IS inside the organization.
Backsourcing: an IS user organization takes at least one outsourced ISD work from the IS supplier(s) to develop an IS back into the organization.
Co-sourcing: an IS user organization and an IS supplier collaborate closely to develop an IS.
Multisourcing: an IS user organization and several IS suppliers collaborate closely to develop an IS.
In all sourcing situations (other than insourcing), there are two different organizations involved in the project. Both organizations have contradictory business goals, in some cases. The supplier lives off its projects and services. So the projects itself are the business, and traditional project performance criteria are preferred in success measures because they are directly connected to supplier business objectives. As discussed before, these measures do not guarantee business success for a client, so the supplier point of view is not automatically optimal for a client. Suppliers therefore tend to harmonize their delivery process, and usually put in place PMOs which oversee that the same process and method is applied. This brings many benefits to suppliers: projects are similar, comparable and, on some level, predictable; people in projects are easily replaceable, so training costs could be minimized like maintenance costs; no resources have to be used to maintain expertise with many methods. They are not behaving irrationally, they are incentivized to behave this way. However, this is supplier organization is also in a collaboration with the client organization which probably does not share this perspective.
For a client, an ISD project itself is seldom the core business but rather a (core) business enabler, and the business objective of an ISD project is to utilize its results as profitably as possible. This is the mantra for good sales pitch to the clients by the suppliers when trying to get the contracts. Suppliers tend to convince the Client that they understand the need very well, and will help them to get there by properly enabling their core business. The client expects the development project to be tailored to the organization’s business development situation; clients do not necessarily benefit much from the supplier’s harmonized and optimized development process.
To summarize, digitalization drives IS client organizations toward new balances between outsourced and in-house ISD by creating strategic incentives for backsourcing and insourcing. IS client organizations, when insourcing, backsourcing, co-sourcing and multisourcing ISD, need to have a sufficient understanding of ISDMs and their selection. Sufficient understanding also helps them avoid lock-ins and high switching costs.
Framework
The vertical dimension of the framework depicts and matches the certainties (characteristics) of current and future business development and IS development. This shows how the characteristics of ISD match those of the related business/organizational development context.
The horizontal dimension matches the certainties (characteristics) of business development outcomes and ISD.
For theoretical clarity, both dimensions of the framework are classified into only two classes. In reality, both dimensions may be considered as continuums. These concepts tie very nicely to the Fact to Fiction continuum ideas presented in Controversy Analysis in a previous post. This is because where the certainties lie on the quadrant below is the discussion that the actors should be having to arrive at a consensus (black box) regarding the programme.
The framework describes four distinct business contexts and categorizes how the two main categories of ISD methods fit each context. Contexts where both certainties are either low or high, provide clear guidelines for ISD method selection. The other two are borderline contexts where either type of ISD method could be used. High uncertainties of business execution cause-effects and low business maturity and business creation, together with high uncertainties of business development outcomes, describe business development contexts where change-driven ISD methods should be selected and used to support and enable business development.
Business process re-engineering with challenging, well-defined objectives and high uncertainties regarding how business processes could be changed and developed to achieve such objectives is a descriptive example of the framework’s right-low corner business context. New business opportunities seeking a well functioning business, for example, by enlarging the business into a new market, is a descriptive example of the framework’s left-high corner business context. In these two contexts, the selection of change-driven ISD methods is probably always a safe bet. However, if the uncertainty is low or can be reduced, then plan-driven ISD methods probably become preferable.
If at the director level, you are able to apply the above and understand the environment in which your innovation is project living and growing, then you will have a better chance of seeing it through. I can cite you many examples, where CTOs have used precisely such an insight (though without theorizing it) to turn some dire situations around. On the other hand, I have also seen situations where the ISDM was thrust upon the innovation group and being a misfit, it caused so much problems that not only did the innovation not come through, but the organization lost good people who left after not being able to stand any further aggravation. One has to understand here that as managers, our role is to ensure that we give a good environment for the doers. Knowledge workers in today's economy have zero issues in accepting a counter offer, so not setting them up for success is a sure shot way to spend more money on headhunting later on.
Advice for Directors
Analyze carefully where your innovation stands on the endogenous and exogenous networks, identify the boundary objects and the obligatory points of passage, get your actor network mapped out on the frontline of socio-technical controversy diagram, and analyze whether your stakeholders are able to qualify and quantify appropriate success criteria. Based on this, then select which model you should go towards for execution and then sign the contracts in accordance with the model. All of this will require you to strategize and engage in many conversations where future success will depend on whether you are able to enroll your entourage to your programme.
