In a rapid changing environment where frantic pace of technology change happens, fixed organizational arrangements or framework can effectively optimize resource utilization. Sharpless organization (Generating new form by recombination) does settle the situation.
Characteristics of Chameleonic organization:
1. Flexibility
2. Movement
3. Transformation
By 1. Interecting; 2. Penetrating; 3. Collating different organizational arrangements
It looks fragmented and intertwined; still it may be the only form capable of surviving in a high-tech
industry where a monolithic, rigid business identity would not seem as able to cope with the frantic pace of technological change.
The organizational structures which support the technology strategy must be able to cope simultaneously with the management of discontinuities and incremental innovation.
This has put, over time, a premium on the firm's ability to develop multiple, often inconsistent competencies, to deal with the emerging, divergent technological and organizational requirements (Burgelman 1983). As a result, existing structures, procedures, and schemes which influence action
are usually under severe strain, and managers end up feeling they are operating in a very fuzzy organizational environment.
The goal of Chameleonic organization:
In different natures, it meets frequent, sudden and radical changes, not just in products, markets and technologies, but in the very business identity and industries to which it temporarily belongs.
Trend in product life cycle:
The distinctive aspect, the product—life cycle is extremely short and is becoming increasingly shorter. Thus, these companies must migrate from one industry to another, and even create new ones, at a pace which would be very fast even for simply implementing product changes within a stable technological horizon.
R&D guideline:The problem of defining the mission and direction of R&D, and in general terms, the global technology strategy, does not consist in choosing an alternative among various product lines or markets, but more radically, in repeatedly asking the question, "what business are we in," i.e., what is the identity of the product, the market, the production process, and the boundaries between what should be done internally and what has to be procured externally, knowing that many of the core innovations are in the hand of external suppliers
Management guideline:
Though managers picture themselves as busy in decision making (forecasting, planning and selecting alternative courses of action) according to the strategy models in good currency, they would be better described as engaged in "sensemaking" (Weick 1979), i.e., in relentlessly picking up the pieces and left-overs of the "broken cosmologies" (past plans, marketing choices, goals, and outlooks) and trying to paste them together in order to make a new sense of t he emerging technologies, markets and industries they are enacting
Bibliography:
Ciborra, C. U. (1996). The platform organization: Recombining strategies, structures, and surprises.Organization science, 7(2), 103-118.
Collection of thoughts, notes and other experiences built-up from my studies and researches
Wednesday, 4 November 2015
Monday, 26 October 2015
[Study] Embracing change with extreme programming
After reading through the article, I had some thoughts:
1. Planning game: Customers decide the scope and timing of releases
=> It is difficult even for PM to perform planning for scope and time. Besides, customers are ambitious so they may try to get the most out of the programmer by setting unrealistic scope and time.
2. On-site customer: A customer sits with the team full-time
=> A assigned customer to the team is currently a staff within a company. This staff must clearly know everything about the requirements so they must be a key staff in the company. It is hard to get them full-time in the project and remove them completely from what they are currently doing.
Bibliography:
Beck, Kent. "Embracing change with extreme programming." Computer 32.10 (1999): 70-77.
1. Planning game: Customers decide the scope and timing of releases
=> It is difficult even for PM to perform planning for scope and time. Besides, customers are ambitious so they may try to get the most out of the programmer by setting unrealistic scope and time.
2. On-site customer: A customer sits with the team full-time
=> A assigned customer to the team is currently a staff within a company. This staff must clearly know everything about the requirements so they must be a key staff in the company. It is hard to get them full-time in the project and remove them completely from what they are currently doing.
Bibliography:
Beck, Kent. "Embracing change with extreme programming." Computer 32.10 (1999): 70-77.
[Case] The Scrum proposal
Please refer to the Link for the case made by my lecturer.
After reading the case, I identified some significant points (P):
P1. Most of the engineer's time is for support and maintenance
P2. There is an increasing trend for the support queue activity overtime (Y1 - Y4)
P3. The current project development process is not suitable for existing product maintenance. Management team and engineers propose Agile iterative development lifecycle.
P4. Agile raises an significant concern related to current certified ISO9001.
My recommendations and support arguments include:
For P1 and P2: I don't see the increase in support and maintenance time is an issue because it is an increasing in customer's demands. The demands come with revenue. The company can make money through supporting and maintenance fee. One of my client back in Vietnam did recognize this opportunity and turn it into revenue by divide a product for a customer to a specific team. The team will follow the product to the end (Development to Maintenance). By this way, each team becomes a profit center. In fact, my client reduced the software package and installation fee (one time revenue) to attract more customers and charge more in support and maintenance activities (recurring revenue).
For P3 and P4: Agile is suitable for support and maintenance as well as ISO9001 with the following modifications:
After reading the case, I identified some significant points (P):
P1. Most of the engineer's time is for support and maintenance
P2. There is an increasing trend for the support queue activity overtime (Y1 - Y4)
P3. The current project development process is not suitable for existing product maintenance. Management team and engineers propose Agile iterative development lifecycle.
P4. Agile raises an significant concern related to current certified ISO9001.
My recommendations and support arguments include:
For P1 and P2: I don't see the increase in support and maintenance time is an issue because it is an increasing in customer's demands. The demands come with revenue. The company can make money through supporting and maintenance fee. One of my client back in Vietnam did recognize this opportunity and turn it into revenue by divide a product for a customer to a specific team. The team will follow the product to the end (Development to Maintenance). By this way, each team becomes a profit center. In fact, my client reduced the software package and installation fee (one time revenue) to attract more customers and charge more in support and maintenance activities (recurring revenue).
For P3 and P4: Agile is suitable for support and maintenance as well as ISO9001 with the following modifications:
- Ensure placed controls and documentations throughout the product development and maintenance processes. (ISO9001)
- Product for a specific customer is now allocated to team. Team lead now will become review bugs, customer requests and assign to the next sprint or iteration.
- Pay more attentions on SLA agreement in term of fee, scope for support, time, and quality of the patches.
Tuesday, 20 October 2015
[Research project] Brainstorming some methods for project requirements gathering
Our group [Me and Phuong Tran] wants to understand the "Dublin Bus" Mobile application (App).
Look:
Still-Photo Survey:
How: Follow a planned shooting script and capture pictures of the people using the App
Why: uncover patterns of behavior and perceptions
Fly on the Wall:
How: Observe and record behavior within its context, without interfering with people's activities when they use app.
Why: see what people actually do within real contexts
Learn:
Combine observation with Character Profiles method
How: Based on observations of real people, develop character profiles
Why: Communicate the value to different concepts to various target groups.
Ask:
Extreme User Interviews:
How: individuals who are extremely familiar or completely unfamiliar with the product and ask them to evaluate
Why: highlight key issues
Combine Interviews with Five Whys method
How: Asking "Why?" questions in response to five consecutive answers
Why: force people to examine and express the underlying reasons
Appendices:
Questions for the interview:
Have you ever use Dublin Bus Application on mobile?
If yes,
[Ask them use the App to perform their regular tasks]
Would you mind if I film your activities?
[If yes, Film their activities when they use the App] [If no, observe]
How many times per week do you use it?
Can you tell me something about the App's functions that you prefer? and some that you don't like and want to improve?
[Apply Five Whys method] for each answer.
Have you ever use other similar app for checking bus/train times, locations, buying bus/train tickets?
Are there any function in other apps that you love? Are there any function that you want Dublin Bus app to have?
[Apply Five Whys method] for each answer.
If no,
[Assist the interviewee to use the App]
and perform the above steps
Besides, here are some extra brainstorming ideas for "Try":
Try:
Empathy Tools:
How: tools like clouded glasses + weighted gloves to experiences the processes
Why: prompt an empathic understanding for users with disabilities or special conditions
=> voice commands
Experience Prototype:
How: quickly prototype a concept using available materials and use it to learn from a simulation
Why: reveal unanticipated issues or needs + evaluate ideas
=> build a app prototype
Bibliography:
Ideo Product Development. IDEO Method Cards: 51 Ways to Inspire Design; Learn, Look, Ask, Try. Ideo, 2003.
Look:
Still-Photo Survey:
How: Follow a planned shooting script and capture pictures of the people using the App
Why: uncover patterns of behavior and perceptions
Fly on the Wall:
How: Observe and record behavior within its context, without interfering with people's activities when they use app.
Why: see what people actually do within real contexts
Learn:
Combine observation with Character Profiles method
How: Based on observations of real people, develop character profiles
Why: Communicate the value to different concepts to various target groups.
Ask:
Extreme User Interviews:
How: individuals who are extremely familiar or completely unfamiliar with the product and ask them to evaluate
Why: highlight key issues
Combine Interviews with Five Whys method
How: Asking "Why?" questions in response to five consecutive answers
Why: force people to examine and express the underlying reasons
Appendices:
Questions for the interview:
Have you ever use Dublin Bus Application on mobile?
If yes,
[Ask them use the App to perform their regular tasks]
Would you mind if I film your activities?
[If yes, Film their activities when they use the App] [If no, observe]
How many times per week do you use it?
Can you tell me something about the App's functions that you prefer? and some that you don't like and want to improve?
[Apply Five Whys method] for each answer.
Have you ever use other similar app for checking bus/train times, locations, buying bus/train tickets?
[Apply Five Whys method] for each answer.
If no,
[Assist the interviewee to use the App]
and perform the above steps
Besides, here are some extra brainstorming ideas for "Try":
Try:
Empathy Tools:
How: tools like clouded glasses + weighted gloves to experiences the processes
Why: prompt an empathic understanding for users with disabilities or special conditions
=> voice commands
Experience Prototype:
How: quickly prototype a concept using available materials and use it to learn from a simulation
Why: reveal unanticipated issues or needs + evaluate ideas
=> build a app prototype
Bibliography:
Ideo Product Development. IDEO Method Cards: 51 Ways to Inspire Design; Learn, Look, Ask, Try. Ideo, 2003.
[Study] On the assessment of the strategic value of information technologies: conceptual and analytical approaches
With years of intensive research, no consensus about strategic value of IT reached. This may due to lack of divergent theoretical frameworks applied.
2 predominant conceptual bases are:
- Resource-centered view (IT as a strategic resource that when combined with other strategic resources directly influence org. performance)
- Production function view: Scale of IT resources [size of IT investments]: consider IT capital and labor to be independent production inputs that can affect a broad range of financial measures.
- Resource-based view: Scope of IT resources [nature or uniqueness of IT applications]: resources confer a competitive advantage to a firm only when they are firm-specific, valuable, rare, inimitable, and nonsubstitutable.
=> strategic resource can produce important benefits for firms (reducing costs and improving revenues)
- Contingency-based view (IT business alignment)
- IT resources per se may add little value and play a major role in improving a firm's performance only when they are planned and used to support a firm's main strategic objectives.
- A possible explanation for the inconsistent findings presented could be that different studies have used different approaches to conceptualize SAIT and measure its effect on org. performance.
=> fit: the degree to which the needs, demands, goals, objectives, and/or structure of one component are consistent with the needs, demands, goals, objectives and/or structure of another component. Extent:
- Adaptation (personal - org)
- Compatibility (individual-org)
- Assimilation (org - org)
- Coupling (inter-exter org)
=> focusing on how IT strategy is developed and implemented in conjunction with business strategy => which the IT portfolio of IT applications is aligned with the business objectives of the firm.
The dynamics of unpredictable environments call for a research approach that can fully capture the relationship between bus. strategy, IT strategy and performance.
Components of SAIT:
- Cost-reduction: most efficient producer (minimize operation
- Quality-improvement:
- Revenue-growth:
=> IT alignment with cost reduction strategy generate more immediate and tangible benefits for firms than IT-strategy alignment that aims to facilitate revenue growth.
=> extracting benefits from strategic IS resources designed to help firms grow is more difficult than extracting benefits from operational IS resources developed to cut costs.
Bibliography:
Oh, Wonseok, and Alain Pinsonneault. "On the assessment of the strategic value of information technologies: conceptual and analytical approaches."MIS quarterly (2007): 239-265.
Saturday, 17 October 2015
[Shadow IT Research] Managing Shadow IT Instances–A Method to Control Autonomous IT Solutions in the Business Departments
Following design science research and guided by a multiple-case study, this research aims towards the design and evaluation of a theoretically justified and practically applicable method to manage Shadow IT
The importance of this long-standing phenomenon rises due to
Occurrences of Shadow IT are applications, spreadsheet and database solutions, cloud services, mobile devices, hardware, support structures, or a combination thereof.
Shadow systems, feral systems, grey IT, rogue IT and hidden IT are equivalent keywords
used in literature for Shadow IT
RQ1: What measures are necessary to manage Shadow IT instances?
RQ2: How can organizations define adaptive and efficient IT Governance structures for autonomous IT solutions in the business departments?
Shadow IT characteristics can be viewed similar to those of informal organizational structures
Both, Shadow IT and informal structures, differ from formal rules. They result from peoples’
need to fill gaps in formal structures to cope with tasks. Both phenomena usually emerge spontaneously, driven by employees on the bottom-level.
Therefore, research examines approaches to access, measure, evaluate, and control informal structures, which can be applied to manage Shadow IT
This decision results from two options on how the business side can fulfill an IT need: Either implementing a solution autonomously or formally initiating a demand at the IT department. This option represents a make-or-buy decision. Transaction Cost Theory is used to explain why institutions insource or outsource capabilities.
Step 1: Identify Shadow IT Instances in the Business Processes
Further research on userdriven IT innovations may focus on the promotion of business-located processes, the distribution of innovations into the organization and the hand-over process to the IT department for established solution.
Comments:
Define Shadow IT: applications, spreadsheet and database solutions, cloud services, mobile devices, hardware, support structures, or a combination thereof.
Approach: user-driven
How: Transaction Cost Theory
=> good article to have ideas for future research
Bibliography:
Zimmermann, Stephan, Christopher Rentrop, and Carsten Felden. "Managing Shadow IT Instances–A Method to Control Autonomous IT Solutions in the Business Departments." (2014).
The importance of this long-standing phenomenon rises due to
- increasingly tech-savvy users,
- easy access to web-based solutions,
- and available end user computing tools
Occurrences of Shadow IT are applications, spreadsheet and database solutions, cloud services, mobile devices, hardware, support structures, or a combination thereof.
Shadow systems, feral systems, grey IT, rogue IT and hidden IT are equivalent keywords
used in literature for Shadow IT
RQ1: What measures are necessary to manage Shadow IT instances?
RQ2: How can organizations define adaptive and efficient IT Governance structures for autonomous IT solutions in the business departments?
Shadow IT characteristics can be viewed similar to those of informal organizational structures
Both, Shadow IT and informal structures, differ from formal rules. They result from peoples’
need to fill gaps in formal structures to cope with tasks. Both phenomena usually emerge spontaneously, driven by employees on the bottom-level.
Therefore, research examines approaches to access, measure, evaluate, and control informal structures, which can be applied to manage Shadow IT
This decision results from two options on how the business side can fulfill an IT need: Either implementing a solution autonomously or formally initiating a demand at the IT department. This option represents a make-or-buy decision. Transaction Cost Theory is used to explain why institutions insource or outsource capabilities.
Step 1: Identify Shadow IT Instances in the Business Processes
Step 2: Evaluate the Shadow IT Instances
Step 3: Control the Shadow IT Instances
Comments:
Define Shadow IT: applications, spreadsheet and database solutions, cloud services, mobile devices, hardware, support structures, or a combination thereof.
Approach: user-driven
How: Transaction Cost Theory
=> good article to have ideas for future research
Bibliography:
Zimmermann, Stephan, Christopher Rentrop, and Carsten Felden. "Managing Shadow IT Instances–A Method to Control Autonomous IT Solutions in the Business Departments." (2014).
[Shadow IT Research] Bringing IT out of the shadows
Article's argument:
Shadow IT: describe the use of unauthorised applications within a corporate environment, and the processing or storage of business information on unapproved devices.
So shadow IT is not a new problem.
The terms ‘rogue’ and ‘shadow’ imply illicit behaviour and malicious motives.
However, most instances of shadow IT are driven by convenience.
Using Tools
Comments:
Define Shadow IT: software
Approach: Using Tools to control
How: Using Tools
=> dont like the idea of using tools as its fixed
Bibliography:
Walters, Richard. "Bringing IT out of the shadows." Network Security 2013.4 (2013): 5-11.
Shadow IT: describe the use of unauthorised applications within a corporate environment, and the processing or storage of business information on unapproved devices.
So shadow IT is not a new problem.
The terms ‘rogue’ and ‘shadow’ imply illicit behaviour and malicious motives.
However, most instances of shadow IT are driven by convenience.
Using Tools
Comments:
Define Shadow IT: software
Approach: Using Tools to control
How: Using Tools
=> dont like the idea of using tools as its fixed
Bibliography:
Walters, Richard. "Bringing IT out of the shadows." Network Security 2013.4 (2013): 5-11.
Subscribe to:
Posts (Atom)