AITS United Kingdomhttp://aits.org/uk
The Best IT Insights in The United KingdomWed, 21 Feb 2018 06:03:22 +0000en-GBhourly1https://wordpress.org/?v=4.9.4Breaking the Code: When Everyone Can Create Technologyhttp://aits.org/uk/2018/02/breaking-code-everyone-can-create-technology/
http://aits.org/uk/2018/02/breaking-code-everyone-can-create-technology/#respondWed, 21 Feb 2018 06:03:22 +0000http://aits.org/uk/?p=86374The buzz is building around the idea of “low-code” and “no-code” platforms, where anyone with a great idea can spin it into existence regardless of technical ability. Such days are not upon us quite yet, but they are coming. In an article for InformationWeek, CA Technologies CTO Otto Berkes discusses the implications of this coming …

]]>The buzz is building around the idea of “low-code” and “no-code” platforms, where anyone with a great idea can spin it into existence regardless of technical ability. Such days are not upon us quite yet, but they are coming. In an article for InformationWeek, CA Technologies CTO Otto Berkes discusses the implications of this coming technology.

Dangerously Simple?

Berkes likens low-code to when graphical user interfaces (GUIs) first emerged: GUIs enabled people to use technology without deep technical understanding, which meant they were free to just focus on accomplishing more work. Low-code is coming at a good time too, when businesses are finally realizing that silos must be torn down and information must be democratized. Berkes continues to say this:

We are entering a world where software programs with many millions of lines of code are not unusual. Increasingly, we write code in combination with existing layers of code, and it’s becoming much harder to test and debug software systems end-to-end. The reality is that code has always depended on other code – the earliest mainframe programs depended on the underlying operating system software. This trend will only accelerate, and even in the most complex of applications, we will be increasingly assembling code from existing blocks rather than staring at a text editor and working on a monolithic program from start to finish.

Berkes finds that there are three implications to consider here:

“Black boxes” of code introduce new security risks.

The new role and shape of IT amid these developments is uncertain.

Skilled people might accidentally be putting themselves out of a job by inventing no-code solutions.

This is only the beginning of the conversation though, because the technology itself is only just starting out. Right now, we just watch and wait.

]]>http://aits.org/uk/2018/02/breaking-code-everyone-can-create-technology/feed/0Building Digital Twins for the Internet of Thingshttp://aits.org/uk/2018/02/building-digital-twins-internet-things/
http://aits.org/uk/2018/02/building-digital-twins-internet-things/#respondWed, 21 Feb 2018 06:02:33 +0000http://aits.org/uk/?p=86372The future is seeing double, at least where the Internet of Things (IoT) is concerned. According to analysts, making the best use of IoT could demand the use of the digital twin, which is a “digital representation of a physical object which also includes data from the object and the ability to monitor it.” Mark …

]]>The future is seeing double, at least where the Internet of Things (IoT) is concerned. According to analysts, making the best use of IoT could demand the use of the digital twin, which is a “digital representation of a physical object which also includes data from the object and the ability to monitor it.” Mark Samuels explains the details in an article for ZDNet.

Dual Fates

The idea of digital twins can be applied to virtually anything in the real world, even whole cities. McDermott International, for example, provides a digital twin in the form of a computer model of its oil and gas platform facilities. How do you begin approaching the creation of a digital twin though? Samuels offers this:

The digital twin comes in two layers. The first layer, which is focused on design, is where the firm captures information on every aspect of its facilities. [Akash Khurana, CIO and CDO at McDermott,] says this layer is a crucial platform, where modifications and changes are updated. “You have to make sure that you have a robust and complete footprint of the design,” he says.

The second layer focuses on operations. Here, data from operational assets is brought in and combined with key enterprise applications. Khurana says this foundational process allows his firm to start creating insights into business processes.

Where should you use this in your business? Well, that is up to you to decide. Each industry is going to find its own uses for digital twins, and maturity will develop in some areas ahead of others. Still, now is the time to begin strategic discussions about where you might be able to implement it to create more value.

]]>http://aits.org/uk/2018/02/building-digital-twins-internet-things/feed/0How to Deal with a Difficult Team Memberhttp://aits.org/uk/2018/02/deal-difficult-team-member/
http://aits.org/uk/2018/02/deal-difficult-team-member/#respondWed, 21 Feb 2018 06:01:54 +0000http://aits.org/uk/?p=86370Some people are just pests, and if you are unlucky, you might find yourself managing one as part of your team on a project. This does not need to be the end of the world though. Maybe, just maybe, you can work with this person and squeeze out a positive outcome. In a post at …

]]>Some people are just pests, and if you are unlucky, you might find yourself managing one as part of your team on a project. This does not need to be the end of the world though. Maybe, just maybe, you can work with this person and squeeze out a positive outcome. In a post at Project Bliss, Leigh Espy discusses the steps you can take.

Pest Control

The first thing you have to do is actually acknowledge the problem exists. Pretending the problem is no big deal only grants the problem a license to fester. Take the person aside and discuss the issue in respectful language:

Focus on the behavior. Don’t use labels or blame. For example, say “You’ve missed the last three due dates” rather than saying “you’re lazy and incompetent.”

Let the team member know the impact that it has on the project or the team. “When the design document isn’t delivered on time, the developer can’t start her work on schedule.” Or “when you shoot down everyone’s idea in the meeting, people become discouraged and don’t want to share.”

And once you say these things, you must listen intently to how the person responds. You want to absorb his or her perspective on the issue and ideally learn something you did not know about the person before. Espy notes that, for instance, it could simply be that there has been a miscommunication about expectations. Bringing the problem to light and uncovering the failed communication underneath might be enough to remedy the situation.

If not, work with the person to build an agreed-upon solution to the problem. Then follow up over time to see if the person is holding up his or her end of the bargain with this solution. If the person really does improve—terrific. And if not, escalate the issue. Get specific about how the person’s performance is not up to snuff and hurting the team. Swat that pest hard.

]]>http://aits.org/uk/2018/02/deal-difficult-team-member/feed/0Before You Set New Goals, Think about What You Will Stop Doinghttp://aits.org/uk/2018/02/set-new-goals-think-will-stop/
http://aits.org/uk/2018/02/set-new-goals-think-will-stop/#respondWed, 21 Feb 2018 06:00:15 +0000http://aits.org/uk/?p=86368Deciding to accomplish something new with your life when your current schedule is already booked solid is impossible. This is a major reason why goals are never achieved—the person just never cleared out enough time to really dedicate to pursuing the goal. In an article for Harvard Business Review, Elizabeth Grace Saunders shares some advice …

]]>Deciding to accomplish something new with your life when your current schedule is already booked solid is impossible. This is a major reason why goals are never achieved—the person just never cleared out enough time to really dedicate to pursuing the goal. In an article for Harvard Business Review, Elizabeth Grace Saunders shares some advice to streamline your time to ensure there is room to achieve goals.

New Goals versus Old Problems

Her first tip is to “question all of your work commitments,” since work is too often assigned in a hurry or in a daze, and there may be no sense of prioritization to it. If you find you have been handed work that would actually be much better accomplished in the hands of someone with more pertinent skills or connections, would it be possible to transfer that work? At the least, have a conversation with your boss and your team to recalibrate on which work is and is not genuinely important. In the end, to visualize your work, you may want to draw out a chart that details each and every one of your professional commitments. All of these activities together should help you start to see where you can free up time in your schedule.

Saunders’s second tip is to reassess your work style, which can take many forms. For instance, you should scrutinize your recurring meetings and ask if it is possible to shorten their lengths or frequency. Or if work interruptions are a problem for you, you might want to create “office hours” of availability and then block people out the rest of the time.

Saunders’s final tip is to be strategic about how you create new goals:

Once you intentionally create space, you can strategically add in the activities that you want in your life. Sometimes that means simply having the ability to take a break during the day and not work at a frenetic pace, or it may mean moving ahead on an important project you’ve neglected for months. Or it may mean being able to reduce your hours so instead of working the second shift at night, you’re hitting the gym or spending time with family or friends.

]]>http://aits.org/uk/2018/02/set-new-goals-think-will-stop/feed/0Squads and Tribes over Silos and Towershttp://aits.org/uk/2018/02/squads-tribes-silos-towers/
http://aits.org/uk/2018/02/squads-tribes-silos-towers/#respondMon, 19 Feb 2018 06:03:22 +0000http://aits.org/uk/?p=86366To phrase it one way, scientific management is the idea that labor should be divided to a point of optimal simplicity so that the processes become reliable in spite of the human dinguses actually doing the work. It is not the most optimistic business philosophy, but its popularity for many years was unchallenged. In a …

]]>To phrase it one way, scientific management is the idea that labor should be divided to a point of optimal simplicity so that the processes become reliable in spite of the human dinguses actually doing the work. It is not the most optimistic business philosophy, but its popularity for many years was unchallenged. In a post at his blog, Joe the IT Guy explains how scientific management still permeates ITSM and how that may not be a great thing in this age of the cloud.

Cogs Can Rust

A major flaw of scientific management Joe identifies is that it feels too impersonal. People are cogs that fulfill their tasks in silos, which is a significant problem these days, as too much work in silos is cited as a reason that many IT projects fail. In other words, process optimization at an arbitrary, granular scale is causing severe inefficiencies at larger, more important scales.

Joe notes that such problems do not exist in modern startups, because their “young founders” just never thought to arrange the business with such a mentality in mind. He shares this breakdown of how Spotify, for instance, describes and models its teams:

Squad – the lowest common denominator, a small “start-up,” sits together, shares two pizzas, etc.

Tribe – multiple squads totaling 100 people or less (approximate to the Dunbar Number); the goal is to eliminate dependencies between squads (effectiveness over efficiency).

Chapter – designed to share learnings and increase economies without dependencies on topics like testing and security.

Guild – so that, on a wider level, individuals can share a wider community of interest across the organization.

Squads are better than silos because squads work toward the good of a product, not toward the optimization of a process. Squads are also measured according to the value they produce instead of just the costs they have incurred. This mentality of value and products over process and efficiency is a needed shift, and it is occurring right now. Are you on the right side of this mentality shift yet?

]]>http://aits.org/uk/2018/02/squads-tribes-silos-towers/feed/0Four Categories of Motivators at Workhttp://aits.org/uk/2018/02/four-categories-motivators-work/
http://aits.org/uk/2018/02/four-categories-motivators-work/#respondMon, 19 Feb 2018 06:02:14 +0000http://aits.org/uk/?p=86364Nobody does work just for the heck of it. There has to be a motivation compelling people to put in the effort. Research has been conducted into the various different ways that people are motivated to complete work. In a post at her website, project leadership coach Susanne Madsen shares Gretchen Rubin’s four categories of …

]]>Nobody does work just for the heck of it. There has to be a motivation compelling people to put in the effort. Research has been conducted into the various different ways that people are motivated to complete work. In a post at her website, project leadership coach Susanne Madsen shares Gretchen Rubin’s four categories of people and how they motivate themselves at work:

Obliger

Questioner

Upholder

Rebel

Upholding Motivation

Each of these categories has to do with how people respond to “internal” and “external” rules respectively. External rules are actually work conditions, such as a deadline set, whereas internal rules are things you set for yourself, such as personal goals. Obligers, for instance, respond very well to external rules because they are people-pleasers. However, they might get so caught up in pleasing others that they forget to watch out for themselves. They also might have difficulty being self-starters, since they want to be doing work that they know for sure is wanted from others. Account for these factors when you know you have obligers on the team.

Next are questioners, which are just what they sound like. They question all of the tasks given to them because they want to confirm there is a valid logic to what is being asked of them. So you had better make sure there is a good reason that you are assigning work to them. In fact, if they do not ask questions, you might want to ask if they have questions anyway, just to save yourself time when they inevitably boomerang back with concerns.

The third category is the upholder. They have respect for both internal and external rules, and frankly, they kind of sound like the best category overall:

They are motivated by fulfilment and by that nice feeling of getting stuff done and achieving something. On the plus side they are self-starters, reliable and don’t need a lot of supervision or accountability. They typically wake up and thinking “what’s on my to-do list today?” On the negative side they need clear rules to be able to operate and avoid letting anyone down. They don’t like to deviate from rules and get frustrated – paralyzed even – when rules are ambiguous or lacking. To others they can come across as rigid or cold. At times they can even make others feel bad because of their high levels of productivity[.]

But should it be the upholder’s problem if someone has his or her feelings hurt over being vastly inferior? Heck no!

Lastly, there are the rebels. Rebels are basically jerks. They do not want to be bothered with anything. You might be able to reverse-psychology them into doing work by challenging their egos, but that sounds like more trouble than it is worth to me. Can you just fire them?

]]>http://aits.org/uk/2018/02/four-categories-motivators-work/feed/0How to Get Engagement for Your Strategic Projectshttp://aits.org/uk/2018/02/get-engagement-strategic-projects/
http://aits.org/uk/2018/02/get-engagement-strategic-projects/#respondMon, 19 Feb 2018 06:01:18 +0000http://aits.org/uk/?p=86358Setting the strategy is one thing, and doing the strategy is another. No matter how great a pitch an executive gives for how strategy will better position business, it will not come to anything if the right projects with motivated workers are not built around it. In a post for Strategy Execution, Elizabeth Harrin shares …

]]>Setting the strategy is one thing, and doing the strategy is another. No matter how great a pitch an executive gives for how strategy will better position business, it will not come to anything if the right projects with motivated workers are not built around it. In a post for Strategy Execution, Elizabeth Harrin shares some advice to spur employee engagement with your strategic projects.

Connect and Empower

To back up a bit—a good pitch for strategy actually is important. More specifically, strategy should be able to be simply conveyed. If the strategy sounds too complex, employees will not understand it. And if they do not understand it, they will not be swayed by it. But if strategy is simple to understand, then employees in turn will be quick to understand which projects do and do not support it.

Once employees have that basic understanding, it is next up to project managers to articulate for their teams how their individual work will help to realize strategy. When a clear line can be drawn from the top to the bottom to show that an employee’s work is genuinely valued by the business, the employee will appreciate that.

Harrin continues to say this:

Another key point where you can emphasise the link between strategy and someone’s day job is decision making. There is a lot of decision making on projects – so much so that someone I met recently said they had decision fatigue at the end of the day and couldn’t answer their child’s question about what was for dinner. It was just one decision too many.

Decisions are easier to make if they link back to strategy. Within a project, you can use the background of your project’s objectives to shape what decision to take. Should we use this risk management strategy or this one? Which helps us stay closer to the objectives? Which supports strategy more naturally? OK, that’s the one you should choose.

]]>http://aits.org/uk/2018/02/get-engagement-strategic-projects/feed/07 Steps to Successful Project Requirements Gatheringhttp://aits.org/uk/2018/02/7-steps-successful-project-requirements-gathering/
http://aits.org/uk/2018/02/7-steps-successful-project-requirements-gathering/#respondMon, 19 Feb 2018 06:00:59 +0000http://aits.org/uk/?p=86356Requirements are the direction and the guardrails on a project. They specify all the general work that must be done in order to satisfy stakeholders and push strategy forward with project completion. In an article for TechRepublic, Moira Alexander shares seven steps to get requirements gathering right: Identify all project stakeholders. Ask stakeholders the right …

]]>Requirements are the direction and the guardrails on a project. They specify all the general work that must be done in order to satisfy stakeholders and push strategy forward with project completion. In an article for TechRepublic, Moira Alexander shares seven steps to get requirements gathering right:

Identify all project stakeholders.

Ask stakeholders the right questions.

Determine the best requirements-gathering techniques.

Document everything.

Analyze the results.

Verify the results.

Obtain sign-off.

A Humble Gathering

While it is not advisable to hunt down literally every single possible stakeholder on a project, it is still crucial to identify the majority of them. Key stakeholders must be identified, but second- or third-tier stakeholders can be just as important. For instance, a lower-priority-but-still-important stakeholder that you have overlooked might come to you late in the project, demanding a change that throws the whole project out of whack. You can avoid such scenarios by being thorough in stakeholder identification and having the right conversations with them early on. Dig deep and have multiple conversations if necessary, since stakeholders themselves may not know what they want at first, and it is up to you to help them make up their minds.

About how specifically to gather requirements, Alexander writes this:

There are multiple requirements gathering techniques that can be used – such as brainstorming, one-on-one interviews, focus groups, direct observation, surveys, prototyping, and reverse engineering – each of which offers specific benefits depending on the nature of the project. Each technique will have its pros and cons; make sure to evaluate each of them to identify the best solution for application. Not all techniques will be suitable for every project. It is best to use more than one technique to make sure the requirements identification is accurate by dissecting things from different angles. This reduces the chances of key details falling through the cracks.

Whatever information you uncover, big and small, document all of it. A detail you think is minor at the time might prove to be a big deal later, so best to play it safe in that regard.

Then comes the time to analyze and verify the findings. Confirm that the results are properly categorized and prioritized, and invite stakeholders to make comment on it and clear up any lingering uncertainties. After that, you are ready to present the requirements to your sponsor for sign-off, and then the project will have formally taken shape.

]]>http://aits.org/uk/2018/02/7-steps-successful-project-requirements-gathering/feed/0There’s More to a System Design Than Requirementshttp://aits.org/uk/2018/02/theres-system-design-requirements/
http://aits.org/uk/2018/02/theres-system-design-requirements/#respondFri, 16 Feb 2018 06:04:53 +0000http://aits.org/uk/?p=67717A few years ago, I was asked to assist on a project where the client was replacing a highly-customized legacy system. As part of the discovery process, we were looking at the integrations to the other systems—internal, third-party administrators, and so on—currently in place. One integration in particular seemed unnecessarily convoluted; it received a file …

A few years ago, I was asked to assist on a project where the client was replacing a highly-customized legacy system. As part of the discovery process, we were looking at the integrations to the other systems—internal, third-party administrators, and so on—currently in place. One integration in particular seemed unnecessarily convoluted; it received a file from one system, validated all of the data, and generated workflows to various roles in the event a particular transaction was deemed invalid. The transaction would stay in the “staging area” until corrected, at which point it would be loaded to the receiving system. I asked how many times these workflows were generated—six or eight times was the reply. Per week, or per day, I asked? Six or eight times to date, throughout the life of the system. Not exactly cost-effective, I thought.

From Design to Implementation to Deterioration

One of the things I’ve found over the years is that all designs begin with requirements, but they end with constraints. During a development or implementation project, these constraints might arise from cost and schedule targets, as well as operational and compliance needs. The project team takes various shortcuts, or they accept a certain inherent error rate, or they take some other action (or inaction) that creates what Ward Cunningham refers to as “technical debt.”

Of course, once a system or program goes into production, the maintenance cycle begins, and Manny Lehman’s law, coined in 1980, becomes operative (paraphrasing): “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.” Maintenance programmers take the already-flawed work of the implementation team and insert additional flaws in a series of attempts to improve it.

Why We Can’t Backtrack to the Origin

Given the system deterioration described above, we should acknowledge that trying to reverse-engineer requirements from a body of code is essentially a fool’s errand. The combined load of technical debt, “nice to have” features added by the maintenance team, and vestigial code from obsolete requirements acts to obscure the original requirements, which will have almost certainly changed since the original program was designed. And yet, we ask to see the code, or at least a file containing the output from a program, as though it will give us what we need more accurately and unambiguously than an interview with the subject matter experts. Apparently, we’re going to replace the old with an essentially identical process, using more advanced technology.

Before replacing a buggy whip with an electric horse prod, let’s take the time to understand what’s different, both in terms of the endpoint systems and compliance requirements, before we design any interfaces. Let’s review the “as-is” with the SMEs, and then ask what should be changed. Let’s try to understand operational rhythms, fault tolerance, and how errors will be handled in production. Let’s see what will be different in the data sources and sinks once one of the endpoints has been replaced. And let’s try not to create a new set of maintenance problems.

Getting to Good Design

There is more to a system design than requirements—there are constraints, and compromises, and an operating environment, and a support model. Good designers take all of these into account, and their designs reflect that. And good implementation teams recognize that the last implementation team also faced requirements, constraints, compromises, and operating and support models, but not necessarily the same ones.

]]>http://aits.org/uk/2018/02/theres-system-design-requirements/feed/0How to Unite Enterprise and Project Risk Managementhttp://aits.org/uk/2018/02/unite-enterprise-project-risk-management/
http://aits.org/uk/2018/02/unite-enterprise-project-risk-management/#respondFri, 16 Feb 2018 06:03:37 +0000http://aits.org/uk/?p=86353Enterprise risk management (ERM) is essentially just what it sounds like—taking a business-wide view of organizational objectives and addressing the multifaceted risks that might arise from pursuing them. Project risk management takes the same principles and shrinks them to the project level. Both are necessary for healthy business, but ERM and project risk management are …

]]>Enterprise risk management (ERM) is essentially just what it sounds like—taking a business-wide view of organizational objectives and addressing the multifaceted risks that might arise from pursuing them. Project risk management takes the same principles and shrinks them to the project level. Both are necessary for healthy business, but ERM and project risk management are not often linked well enough. In a post at the Project Risk Coach, Harry Hall discusses how to more effectively unite the two. It begins with defining the organization’s vision, mission, and values, and then deriving goals from those factors. From there, strategic mapping ensues in how to best apply risk management practices cohesively.