Agile Enterprise Solution Architecture

Enterprise Architecture (EA) as an enterprise planning framework has its place and merits, yet it often falls short of real-world IT expectations. The traditional EA approach defines the to-be state architecture that may exist for a while but does not last long. In most cases, an enterprise architect starts from existing architecture and makes improvements. Such improvements are constantly needed as complex systems EA guides and expects are subject to constant changes. In practice, an enterprise architect is either engaged in strategic planning (including business modeling) or solution-oriented architecture. Most of the routine work of enterprise architects, in fact, involves crafting application or technical architecture. Therefore, what really matters in the IT world is an Enterprise Solution Architecture (ESA) that inter-mingles EA with Solution Architecture (SA) and provides holistic yet pragmatic modeling to enterprise information systems, along with an incremental and iterative approach for agility.

Agile Enterprise Solution Architecture mainly covers five areas: 1) enterprise capability (enterprise-wide organizational considerations of strategic planning, business context, and relevancy), 2) requirement/case scenario (business process and functionality required for enterprise IT systems), 3) architecture overview (including traceable business measurements, architecture patterns, and architectural metrics such as principle, risk, architecture decision, etc.), 4) IT functional service (relationship/interaction, granularity, etc.), and 5) IT infrastructure (operational aspect).

Within this architecture, all high-level statements (business initiative, process, and the like) need to be clearly mapped into ESA elements before they can become part of the architecture. Importantly, the IT service serves as a liaison between the enterprise blueprint and solution architecture. Its focus is on different levels of service interaction, service offer, and service system. At the functional level, for example, IT services can be categorized as interaction service, application logic service, data service and technical service.

Agile ESA helps clarify enterprise-level issues and key stakeholders’ major concerns (or the architecturally significant concerns) by forming critical architectural thinking blocks, especially those in between enterprise strategies and capabilities, business domains and applications, and applications and technologies. For this purpose, it:

◉ Maps inputs from all stakeholders including implicit requirements or objectives

◉ Introduces key architectural metrics to reach realistic architecture decisions

◉ Employs techniques for service abstraction, service interface, and service realization

◉ Incorporates an analysis process for architectural modeling assurance and governance

◉ Advocates just enough architecture and significant architecture of value streams

◉ Instills T-shaped IT expertise via a modeling framework to balance the enterprise capabilities and IT service modeling at the right level of abstraction and correlate between different architectural aspects (business and IT, application and technical, functional and operational, logical and physical)

As a modeling framework, Agile Enterprise Solution Architecture targets the following objectives:

1. Simplified: Eliminate unnecessary complexities in a traditional enterprise architecture, and simplify various architectures into a core model for easy learning and wider adoption

2. Panoramic: Take a holistic approach to trace back and forth key architectural elements (business, technical, and alike), and make enterprise architecture readily applicable and pragmatic

3. IT Service-oriented: Focus on enterprise capabilities and IT services (the primary elements), strike a proper balance between enterprise architecture’s strict definitions and solution architecture’s granular details, resulting in IT service architecture delivery (rather than traditional roadmap, business entity, product, or component)

4. Adaptable: Apply to various architectural styles (enterprise or solution, emergent or intentional, cloud-native or monolithic, software or system-scale, business or application) for ready customization and extension, and architect for changes to meet enterprise growth

Source: opengroup.org

Continue reading

How to Use Microservices: A Guide for Enterprise Architects

Many organizations have started to break up a portion of their monolith applications and systems, transitioning to sets of smaller, interconnected microservices.

A recent survey by TechRepublic, found that organizations who used microservices were reaping clear benefits: 69% were experiencing faster deployment of services, 61% had greater flexibility to respond to changing conditions, and 56% benefited more from rapidly scaling up new features into large applications.

But when are microservice architectures the best option? When can they offer the most value to an enterprise? And how do they fit in the enterprise architect’s toolbox?

The Benefits of Microservices

Consider a car production assembly line, where task specialization has been introduced to manufacture each part. Individual tasks become more efficient due to dedicated resources, operations, and labor. These newly generated efficiencies drive greater productivity and output, benefiting the overall process. 

Similarly, in microservices, or microservice architectures, separate modules are responsible for building and maintaining different components of the end-product. Individual units can be modified and scaled without disrupting the other parts. In contrast, implementing changes to a single, large “monolith” module, can be difficult to manage and can quickly become complicated.

Microservice vs. Monolith Architectures

The O’Reilly Microservices Adoption in 2020 report found that “77% of respondents have adopted microservices, with 92% experiencing success with microservices.” 

While the advantages of microservice architectures are plentiful, there are also tradeoffs to consider when comparing to monoliths.

In short, microservices still need to be “architected”:

◉ Communication between separate services is more complex. As large applications can contain dozens of services, managing the interactions between modules securely can add extra challenges.

◉ While microservices allow for different programming languages to be used, the deployment and service discovery process is more complicated. A broader knowledge is needed to understand an application’s full scope.

◉ More services equal more resources. For the car manufacturing example above, each task station requires individual tools, workers, and processes. Likewise, a single service may call for a dedicated database, server, and APIs.

How and when to Migrate a Monolith to a Microservices Architecture

When deciding if a microservice architecture is the right option, enterprise architects need to consider their organization’s goals and concerns.

As it’s uncommon for new architectures to be built from the ground up, a migration from one state to another is the most likely scenario. This transition begs the questions: What does the current architecture allow? What does it limit? What are we trying to achieve?  

Sam Newman, author of Building Microservices: Designing Fine-Grained Systems, suggests starting with Domain-driven design or DDD. This modeling exercise enables an organization to “figure out what is happening inside the monolith and to determine the units of work from a business-domain point of view”.

Considerations when Building a Microservice Architecture

Once an enterprise architecture practice has settled on migrating from one architecture to another, the team can ensure the process is heading in the right direction by:

◉ Determining the level of modelling detail;

◉ Deciding on the applied properties, and;

◉ Setting appropriate KPIs.

Microservices (Integration layer) dashboard in ABACUS

As different microservice platforms have different approaches to service classification, classifying an organization’s microservices should be a key priority.

One commonly used approach is to categorize services across the 3-layers of: Experiences, Processes and Systems. The diagram below illustrates this approach, using 3 layers of integration components for business services/events.

Microservices Modeling in ABACUS using an Extended metamodel for Integration Services in 3 layers: Experience, Process, and Systems

The Process of Mapping Microservices

It’s straightforward to model microservice architecture. The following 7 steps can help to inform your modeling process:

1. Adapt the metamodel to support microservices. ABACUS provides a number of architectural patterns which can be used to update your current framework for this purpose.

2. Populate the microservices portfolio to enhance the production architecture of the microservices layer. Use the data you have already uploaded or integrated with ABACUS.

3. Add properties and values to further develop the architecture

4. Create views such as Microservices Portfolio, Microservices Solution View, Microservices Dependency Views, etc.

Layered Microservices Modelling using Application Services and Application Interface in ABACUS

Microservices Modelling using “Publisher – Broker – Subscriber” Pattern in ABACUS

◉ Establish the relationship between microservices based on data flow and services orchestration.

◉ Design and implement analytics such as microservices cost, complexity, and availability.

◉ Develop a reporting dashboard and assess integration scenarios (see above example Microservices (Integration layer) dashboard).

Source: opengroup.org

Continue reading

Developing a Standard Service Model Using the ITIL 4 Guiding Principles

If you’re a large organization, or an IT service provider offering services to large enterprises, then reviewing your standard service model on a regular basis is imperative. Ensuring that it stays aligned with your business and IT strategy. Especially because understanding the outcomes your customers need is difficult in an evolving and changing business world.

What’s a standard service model?

Well, if you provide a wide-ranging and complex set of IT services to your customers, then balancing return on investment (ROI) and value on investment (VOI) for customers is likely to be a challenge. Having a standard service model that delivers a standard set of outputs for your customers across your services could be the answer you’re looking for.

The benefits are economies of scale for your operational areas, a better understanding of your cost base, and every stakeholder in your service relationships knows what you’ll deliver (including, of course, the customer).

Using ITIL 4 to create your standard service model

To assess the status quo within your organization, and any existing service model(s), a great tool to use is the ITIL continual improvement model – which was called continual service improvement (CSI) in earlier versions of ITIL (please see the diagram below).

Source: AXELOS, Continual Improvement ITIL 4 Practice Guide

In addition to employing the continual improvement model as a way of reviewing and assessing the current standard service model position, even if you haven’t got anything in place right now, there’s also the ITIL 4 guiding principles.

These can be extremely beneficial when looking to ensure that the newly created model is fit for purpose.

How the ITIL 4 guiding principles can be used to create one

Guiding Principle	Standard Service Model Application
1. Focus on value	Understand what makes your customer successful, how their business works. The service model should be designed to enable and deliver the outcomes and the value they need.
2. Start where you are	Normally a service provider will have a wide range of established processes, procedures, and documentation. Take the best and use it. There’s no need to start from scratch (unless you feel you have to).
3. Progress iteratively with feedback	The service model is likely to be quite complex, so approach it in an agile way, i.e. in small, bite-sized chunks, and get continual feedback from stakeholders to ensure that it’s fit for purpose. Then release regular iterations which will deliver value sooner.
4. Collaborate and promote visibility	The service model is likely to be quite complex, so approach it in an agile way, i.e. in small, bite-sized chunks, and get continual feedback from stakeholders to ensure that it’s fit for purpose. Then release regular iterations which will deliver value sooner.
5. Think and work holistically	The service model will work across the organization, not just within IT operations. It will also – depending on if you’re an internal or business-to-business (B2B) service provider – impact product development, sales, bid teams, and delivery management. So, consider the end-to-end requirements and design the model accordingly.
6. Keep it simple and practical	Keep the model simple, because stakeholders will understand it better and it will be easier to deploy. Focusing on getting value delivered in the most straightforward way will also help to keep the model up-to-date and relevant.
7. Optimize and automate	Optimize the service model by making things as simplified and efficient as they can be, then look to automate where possible. This will introduce additional efficiencies. However, please don’t automate just for the sake of it – focus on what value the automation will bring.

Getting a standard service model right is not an easy task in a large organization. However, the value it’ll bring is enormous.

Source: itsm.tools.com

Continue reading

Adopting ITIL 4 Using PRINCE2

Have you considered using PRINCE2 to help with ITIL 4 adoption? With the advent of ITIL 4, more and more organizations around the world are beginning to realize that IT must bring value. It’s a key reason why many companies want to incorporate ITIL 4 into their organization. For example, are any of the following expressions familiar?

◉ “We want to elevate IT to a strategic position in the business, and ensure that it contributes to our vision and objectives.”

◉ “We need to find savings in IT. We need to be operating as efficiently as possible.”

◉ “Our customers are not happy with the products and services we’re providing. How can we get better?”

In my opinion, we can all be better if we adopt ITIL 4 practices into our organizations. And this article looks at how the use of PRINCE2 will help.

The applicability of PRINCE2 to ITIL adoption

In my experience, many companies are reporting that: “Deadlines are delayed, costs are rising, and the motivation of specialists is decreasing. Quality suffers as a result.”

To avoid these issues and to bring your organization up to a new level of IT service delivery and support, I suggest adopting ITIL 4 using the PRINCE2 framework. This was developed under the auspices of the UK government to manage IT projects but has since undergone significant changes to adapt it for other industries.

Why do I think of ITIL 4 adoption as a project? Project management is the management of the change process required to achieve an end target, within certain time and cost parameters. ITIL 4 has no end target. However, we do have end targets when implementing certain ITIL 4 practices and adding value to our services. And this is a project.

This is a classic PRINCE2 process map but, if you’ve undergone any related training, you’ll remember that we tailor the PRINCE2 methodology to our project environment.

An example of using PRINCE2 for ITIL 4 adoption

ITIL 4 adoption can be done either by an internal team or by using external consultancy services. I’ll reflect on how to use PRINCE2 in both scenarios.

Starting up an ITIL 4 adoption project

A project mandate is the trigger for the project. Do we have clear reasons for adopting ITIL 4? What do we want to achieve? Which practices and elements from ITIL 4 do we want to include in this project?

Adopt ITIL, if there is a business justification for it, and only in this case.

Once all the necessary authorities exist for initiating the project, sufficient information is available to define it, and the scope of the project is confirmed, appoint individuals to undertake the work required for project initiation.

The project brief should be developed using the ITIL 4 guiding principles such that time is not wasted initiating a project based on unsound assumptions (scope, timescales, acceptance criteria, and constraints).

Directing an ITIL 4 adoption project with PRINCE2

Management direction and control are provided throughout the project’s life, including to help ensure that the project remains viable. I’d highly recommend including all C-level personnel on the project board. If you’re doing the project with an external consultancy company, a senior manager from the consultancy company should be included as well.

The project manager and the project team are assigned. If it’s your internal project, then the project manager should be an individual from your organization. If you’re using an external consultancy company, then the project manager and team roles should be taken by a principal consultant and consultants from the external company.

The project board should be involved in all project stages.

Initiating an ITIL 4 adoption project with PRINCE2

Consider ITIL 4 a product. Start with an assessment and gap analysis. At this point, the ITIL 4 guiding principles start to apply. This will show “Where are we now?”

Use value stream mapping to identify pain points and improvement opportunities, such as eliminating waste and blockers, start collaborating, etc.

Prepare a continual improvement register (CIR) based on the assessment, gap analysis, and value stream mapping. Control and monitor risks at all stages.

Define the project plan based on the CIR by stages. Adopt ITIL gradually. Ensure that each stage is measurable. Start where it’s most necessary or advantageous.

Controlling a stage

The project manager using PRINCE2 needs to focus on the delivery of the stage’s products. Risks and issues, and business case are kept under control and review. The agreed-upon products for the stage are delivered to the stated quality standards, within cost, agreed-upon effort and time, and ultimately in support of the achievement of the defined value.

Work packages are used to define and control the work to be done and to set tolerances for the project team. Work packages should be small pieces of improvement that are iterative and are going to add more value to day-to-day work.

Managing product delivery

The ITIL 4 guiding principle “progress iteratively with feedback” applies here. Once small pieces of work are implemented, provide a workshop. I’d highly discourage writing a stack of policies or processes first. Act iteratively, and don’t try to “eat the whole elephant.”

Don’t adopt ITIL 4 practices just for the sake of a “tick.” Start with small pieces. Set yourself achievable goals for a limited period. Then, ask yourself the question: “Did we get what we expected?” Analyze the challenges and bottlenecks, and gather feedback from IT staff and end users. Plan for further iterative practice development.

Managing a stage boundary

Assure the project board that all products in the stage plan for the current stage have been completed and approved. Review and, if necessary, update the project initiation document (PID) using PRINCE2 practices.

Provide the information needed for the project board to assess the continuing viability of the project – including the aggregated risk exposure and a record of any information or lessons that may help later stages of the project and/or other projects.

Continual improvement with PRINCE2

You might have expected to see a “closing the project” process here. However, with an ITIL 4 project, it’ll never come to the end. Always improve. Review the performance of the project against its baselines in the CIR. Assess any value that has already been realized, update the forecast of the remaining value, and plan for a review of the unrealized value. Also, ensure that provision has been made to address all open issues and risks with follow-up action recommendations.

Visualizing project element relationships

While the above will read in a very linear way, the reality of your ITIL 4 adoption project will be more like the image shown below.

Also, no matter which ITIL 4 practices you decide to adopt first, in my experience the service catalog should be one of the first project deliverables. This’ll lay the foundation for the development of a service-oriented culture in the organization.

Source: itsm.tools.com

Continue reading

What Kind of IT Organization Do You Work in?

How did your IT organization, group, or department fare during the global pandemic? If you’re looking to classify its performance – after all, we love to classify things in IT, then our research identified three distinct groups in terms of performance. These can be segmented approximately by their IT maturity but also the role of the IT leader in their organization:

1. The Fallen. These are the IT groups that tried, but failed, and have already been outsourced, or absorbed by shared services. Low levels of maturity, historic under investment in systems, and wider adoption of cloud technology by non-IT functions accelerated their decline.

2. The Chasing Pack. These are the IT groups still progressing their journeys but will not be there any time soon. The vast majority of the industry is playing catch up and trying to align with the transformation required. With 40% of boards thinking that IT can be outsourced, their success is not guaranteed.

3. The Climbers. These are the IT groups that delivered order from chaos. They represent a small percentage of the industry, with high levels of IT maturity, skills, and experience in place based on previous digital transformation plans, and an IT leader who has a seat at the exec table.

Each of these is described in more detail in the remainder of this article.

1. The Fallen IT Organizations

These IT groups are a clear signpost to the industry of what will happen if IT does not align with business requirements and enable transformation. In good times, businesses will tolerate a degree of waste and inefficiency, but when times get tough, the focus of organizations naturally turns to cost containment. Now, more than ever, IT groups that are not seen to be adding value face the threat of outsourcing. Before the pandemic, the writing was already on the wall for IT groups in this category.

In 2017, research by McKinsey & Co found that more than 40% of business executives believed that IT could be significantly or fully replaced by third-party services, with minimal impact on the business. Although senior IT executives did not share that opinion (80% difference), the pandemic has already driven a significant increase in outsourcing.

In both Q3 and Q4 2020, the value of UK outsourcing contracts increased by 60% compared with the previous year. Alongside the rise of managed service providers (MSPs), the shared services approach is also gaining traction, especially in the public sector. Organizations within the same market sector are pooling their resources and reducing costs by enabling efficient service delivery teams to absorb the user base of poor performers.

Within the Fallen group, the business mandate for IT has always been to: “Run faster, better, and cheaper than last year.” IT is perceived as transactional, undeserving of a seat at the table, and executives make business decisions without IT involvement.

A common symptom of IT groups in this category is chronic underinvestment. As a result, legacy technology prevails, and siloed IT teams are forced to stick with the same old tools for years. Teams are flat out managing older technology, and there’s never enough time, money, or resources to change. Now, change has been forced upon them, and in the era of hyper-transformation, they’ll struggle to survive.

2. The Chasing Pack

Businesses in the Chasing Pack see value in their IT functions. They may not be able to quantify IT value in terms of contribution to business goals, but neither can IT. Although the CIO’s voice occasionally reverberates at the boardroom table, IT is still perceived as a supporting function, a means of driving efficiency, and investment is typically limited to 3-5% of the overall business budget.

IT groups within this group are primarily focused on frameworks. Efficiency is measured using IT metrics based on demand, workload, and service level performance. ITIL adoption delivers a step change, which encourages further investment, and slow and steady adoption of increased levels of best practice. Maturity assessments and positioning on IT maturity models reveal a stark reality, with most IT groups stuck between levels 2 and 3. Unable to break through the glass ceiling, IT groups look for tools to increase their ITIL capabilities.

Here the selection process often ends with the procurement of an overly complex, expensive tool, with more functionality than the average IT group can deploy in a lifetime. When the new tool is implemented, the initial focus on service improvement makes things better, but only for a short time. Once the tool has bedded in, the focus on improvement usually stops. Mediocrity takes over, the tool gets blamed and the whole cycle is repeated, without any attention paid to the lessons learned from the previous experience.

The pandemic may have taught groups within the Chasing Pack that they cannot continue to water their IT garden while the rest of the house is on fire. But if this lesson has not been learned, it will soon become apparent when these groups seek budgetary approval for new tools.

Given the expected pace of change this year, IT groups in this group must raise their game. The focus must shift from supporting infrastructure, to supporting people, and from delivering services, to delivering outcomes. As the office decentralizes, and infrastructure races to the cloud, the traditional perception of IT as a service provider must be challenged. Importantly, IT teams and systems that are designed for triage, will not deliver transformation.

3. The Climbers

As the pandemic hit, IT groups in this category were better prepared. Modern technology and self-sufficient IT teams enabled their organizations to adapt quickly. This allowed them to keep climbing ladders and break through the self-imposed glass ceiling of the Chasing Pack.

IT groups in this category apply a systems thinking approach and understand that if you focus on managing cost, the cost goes up because you design for failure demand. Whereas, if you focus on value, the cost comes down. They also understand that value is based on customer perception. It cannot be delivered using inside-out approaches based on guessing. Instead, they take an outside-in approach, get close to their customers, understand their challenges, and co-create highly visible value.

Important IT groups in this category can answer these four questions:

1. Who are my customers?

2. Which activities do they perform in pursuit of their success?

3. How do we support them with those activities?

4. What do they say about our service?

Respected and supported by the business, the Climbers can afford to keep their service management tools up to date, and they regularly review innovation within the market. When specifying and deploying tools, they prioritize user experience over shiny new IT toys and slavish adherence to frameworks. They want self-sufficiency, and the ability to design, automate, and integrate processes without the need for projects, partners, and technical gurus. These IT teams are effective at triage, but their focus is transformation, and they’re trusted to lead.

At the height of the crisis, they deployed solutions for other business areas. Analog teams with heavy dependencies on manual processes were suddenly introduced to new digital experiences that made life at work better. The genie is out of the bottle, and there’s no going back now.

So where does your IT organization sit?

The Fallen have been outsourced or absorbed. Can IT teams in the Chasing Pack cope with a huge increase in the adoption of new technologies, an incredible pace of change, and a business outlook that will be less tolerant of waste and inefficiency? Make no mistake, in the current climate getting this right is vital, and the danger of not doing so is real.

Source: itsm.tools.com

Continue reading

What Tools Do Business Analysis Professionals Use to Manage Cybersecurity Analysis?

Since early 2020, organizations have faced a plethora of cybersecurity issues. Take ransomware attacks, for example. They have increased by 148% due the pandemic, according to AFCEA. This is just one of hundreds of discouraging cybersecurity statistics. Business analysis professionals skilled in cybersecurity analysis can help keep company networks secure during this time of heightened cybercrime.

Read More: IIBA Certification

Business Analysis vs. Cybersecurity Analysis

Business analysis is both a role and a discipline. IIBA defines a business analyst as an agent of change who uses the discipline of business analysis to introduce and manage organizational change for businesses, governments, or not-for-profits. Job titles for business analysis practitioners include not only business analyst, but also business systems analyst, systems analyst, requirements engineer, process analyst, product manager, product owner, enterprise analyst, business architect, management consultant, business intelligence analyst, data scientist, and more.

Cybersecurity analyst is a different role than the business analysis professional, but they have many commonalities. For example, cybersecurity analysts perform business analysis tasks, as well as take measures to secure an organization’s computer systems and networks. Rasmussen University explains that cybersecurity analysts are responsible for reporting breaches and network weaknesses, researching IT trends, and educating end users on cybersecurity.

Often, an individual starts out as a business analysis professional, learns about cybersecurity and then earns credentials that give them the competence to assume a cybersecurity analyst role. IIBA and IEEE Computer Society  have partnered to offer a robust learning and certification program on Cybersecurity Analysis and is one program to consider.

6 Tools Cybersecurity Analysts Use to Do Their Job

Cybersecurity analysts use a variety of tools to secure networks and computer systems. Here are a few examples:  

1. Encryption tools - Encryption software allows cybersecurity analysts to encrypt and decrypt a data stream, whether it is at rest or in transit. This keeps vulnerable data from being seen by unauthorized users.

2. Network Security Monitoring Tools – Network security monitoring tools help cybersecurity analysts monitor a network to keep it safe and free from intrusion. Examples of these tools include Argus, Nagios, Splunk, and OSSEC.  

3. Web Vulnerability Scanning Tools - Web vulnerability scanning tools provide insights into cybersecurity weaknesses. These tools enable a cybersecurity analyst to determine what security threats an organization is facing.

4. Antivirus Software – By installing an appropriate antivirus software solution, a cybersecurity analyst can protect a network from malware. Microsoft Defender, Malwarebytes, and McAfee Total Protection are some examples of antivirus software.

5. Penetration Testing - Cybersecurity analysts often include penetration testing in their cybersecurity toolbox. “A penetration test, or pen test, is an attempt to evaluate the security of an IT infrastructure by safely trying to exploit vulnerabilities,” explained CoreSecurity.  

6. Network Intrusion Detection Systems - A Network Intrusion Detection System (IDS) is a software application designed to allow cybersecurity professionals to detect policy violations or malicious activity on a network. A few examples of an IDS include Suricata, SolarWinds Security Event Manager, and OpenWIPS-NG.

Source: iiba.org

Continue reading

Top 3 traits of continuous learners (and why they are important)

In project management, swatting up is about more than a quest for knowledge. Continuous learners help their organisation stay ahead of the curve. They can be instrumental in driving business change, implementing new processes, and leading projects to success. Continuous learners are in high demand. Their in-built desire to learn is hugely valuable in improving the company’s prospects.

Likewise, for the individual, professional development has immeasurable importance for their own prospects. Through studying, striving to know more, researching and training, a continuous learner can develop and broaden their skillset, and ultimately advance their career.

So do you have what it takes to be a continuous learner? These are the top three traits to recognise and develop:

A growth mindset

If the pandemic has taught companies anything, it is the importance of adapting to changing needs. Only through continuous growth can we be equipped to successfully navigate change, and individuals with a growth mindset will find navigating change far easier than those with a steadfast mindset. Continuous learners possess agility and adaptability – key skills when it comes to change management.

Business change is less about keeping up, and more about getting ahead. Equipped with a growth mindset, continuous learners have the ambition and drive to seek out new growth opportunities. What’s more, they have developed talents and capabilities to problem solve effectively, and to innovate.

How to develop a growth mindset: (The good news is that any of the attributes we are highlighting here can be developed.)

A growth mindset can be learned. First, you must recognise if you are guilty of having a static mindset. Do you treat the knowledge you possess as set-in-stone? Is your approach to work and projects led by unchanged, hard and fast rules? If so, it could be time to pursue professional development training such as PRINCE2 Agile. The PRINCE2 Agile course bridges the gap between the PRINCE2 methodology and Agile practices. The best of both worlds, if you will! With new approaches and processes, you onboard new ways of thinking, and become more likely to take on challenges.

An inquisitive nature

Gone are the days when it’s frowned upon to have a host of different jobs on your CV in favour of a ‘specialism’. A variety of roles signifies that you are curious, you have an inquisitive spirit, and that you have chased diversity in your experience. Progression is rarely linear, it sidesteps, back steps and sometimes even leaps ahead. For continuous learners, progression comes from an inquisitive nature and their hunger to know more.

Exposure to a variety of environments means individuals acquire new aptitudes on an ongoing basis. This form of continuous learning builds a diversity of experience. Individuals with an inquisitive nature can prove crucial to project teams chasing ambitious goals, as they prove they are always open to learning more and tackling new challenges. Look for these characteristics and behaviors within yourself.

How to develop an inquisitive nature: (Again, the good news is that any of the attributes we are highlighting here can be developed.)

Think back to a time when you landed a role only to discover you felt out of your depth! Perhaps you didn’t know how to work the software your new company used, or some of the industry-specific language was jargon to you. You may even have felt ‘imposter syndrome’, and like you didn’t belong in the position. How did you handle this situation?

Situations like these often trigger a fight or flight reaction. Did you stick it out, take it upon yourself to learn, fill the gaps in your knowledge and rise to the challenge? That kind of initiative is what you need to channel in your everyday work! Be aware of how you act and react when you’re in unfamiliar territory. Get curious, ask questions, read and research. Talk to your colleagues too. Team members with specialisms are an untapped resource! Nurture curiosity and turn it into discovery in order to grow and progress in your work.

The desire to take risks

The third key characteristic of a continuous learner is their desire to take risks. Playing it safe is predictable and a continuous learner prefers to find out what happens if they take the risk. Only by jumping at possibilities and opportunities can they gain knowledge. Whilst this may sound reckless to some, continuous learners have optimism. They know that risks must be taken when trying to solve problems and that even failed risks provide an opportunity for growth.

Having the courage to take risks goes hand in hand with our first trait – a growth mindset. A continuous learner has the agility and resilience to know that if they take on challenges and make mistakes, they have the toolkit to recover from it.

How to develop an inquisitive nature: (Any of the attributes we are highlighting here can be developed.)

Being able to adapt to unforeseen circumstances is key to having the confidence to be a risk-taker. And so, building Agile skills will teach the ability to be responsive to the environment, and how to respond when a project changes course. To build your confidence further, simply start taking risks. Begin with small experiments and you will soon develop the bravery to take bigger leaps of faith. Be sure to always reflect and learn lessons from failures in order to grow and advance from them. You will progress your talents and your projects will triumph. Before you know it, you will thrive by taking risks!

Source: prince2.com

Continue reading

Service Desk Improvement – 5 Steps to Drive Collaboration

If you want to drive up employee collaboration on your IT service desk, within wider IT operations, and across your organization, then this article is for you. Within it, I outline five key steps for improving your operations and outcomes through the creation of the right environment for effective collaboration. Step 1 starts with collaboration on the service desk, with the following four steps talking to enterprise-wide collaboration.

Step 1: Reduce the pressure, and make the room for increased collaboration, with self-service

When implemented effectively, self-service is arguably one of the most effective ways to significantly reduce the burden on the service desk. In Hornbill’s experience, when self-service is designed with the primary objective of improving the employee service experience, with rich knowledge, FAQs, and instructional videos coupled with the ability to automate simple tasks, employee adoption soars. Such that the service desk benefits from reduced ticket volumes and the ability to deal with incoming incidents/requests in order of business priority.

If self-service is working well, and helping you triage tickets effectively, you can enable teams to swarm and collectively address issues that are higher priority. By openly discussing issues in collaborative workspaces, your IT support personnel can draw experts into discussions, share information and expertise within tickets, and capture vital knowledge as work gets done. Extending collaboration beyond the service desk.

Step 2: Acknowledge the barriers to collaboration

Research conducted by the Harvard Business Review – that’s documented in How Collaboration Wins – highlights a series of barriers to successful collaboration in organizations. Importantly, collaboration is not just about technology. In fact, technology being difficult to use is at the bottom of the list of barriers.

The top three barriers to successful collaboration identified by the research are:

1. Siloed organization and lack of inter-departmental working (67%)

2. Risk-averse culture (35%)

3. No clear vision from leadership (32%).

Step 3: Recognize that the role of leadership is critical

The Harvard Business Review paper “Eight Ways to Build Collaborative Teams” highlights the behavior of the senior leaders in an organization as one of the most important factors that drives success in adopting collaboration. In short, behavior sends a far stronger message than other mediums. Execs need not only to articulate a clear vision of what’s required, and the benefits of adoption, but they must also “walk the talk.”

The most successful leaders are those who – in the early stages of shifting their organization towards collaboration – are task-orientated, communicate clear goals, engage in debates, and clarify the responsibilities of team members in the transition. As the organization shifts to new ways of working, leaders need to provide good feedback, often. The new culture needs fostering and reinforcement.

Step 4: Technology must be the change enabler

Research from McKinsey, Accenture, and Deloitte emphasizes that automation and the ability to painlessly adapt business processes and realign business models around collaboration are fundamental. Collaboration is not, and cannot, be a separate “thing.”

Today, as the world recovers from the pandemic, IT needs to respond to two questions: (1) How can we facilitate the digital translation of meeting rooms and common areas for socializing to replace the physical environment? and (2) How can IT work with senior management to ensure the ecosystem of collaboration tools provides consistency of use and process?

Importantly, collaboration needs to be embedded into operations – and the technology that’s employed – to ensure it plays an integral role in supporting business processes.

Step 5: Watch out for the common pitfalls of collaboration

We frequently hear of IT teams, and the wider business, rolling out collaboration platforms with an initial surge of adoption, which fails to stick, then quickly fades away. Whether it’s Microsoft Teams, Slack, or another of the numerous collaboration tools that are commonly used, the challenge is the same. These tools are not ‘destination applications’ i.e. they’re not the tools that employees open first when they arrive at work. For most people, the primary destination application is email. 

Source: itsm.tools.com

Continue reading