Automation and Autonomics – Effects on the Workforce

by Bill Fowler

Automation introduces major changes to the workplace. There will be questions about how it will affect productivity, the workforce, and the way organizations are run. In order to prepare for the future of automation and autonomics, it is critical that organizations examine how this rapidly changing technology will affect their business model, profitability, and employees.

How will A/A affect the workforce?

Perhaps the single greatest concern about automation is its effect on the workforce. This fear has slowed the adoption of automation, as there is often great pushback from employees. Historically, automation has actually had little to no correlation with unemployment. Although German industries installed a far higher proportion of robotic equipment between 1997 and 2007 than industries in America, they actually saw less job loss in the manufacturing sector. Other data show that there is an essentially flat correlation between the percent change in use of automated systems and percent change in unemployment across countries all over the world1.

How will it impact employees?

Although automation may not lead to job loss on the whole, it can still have a significant effect on employment and work activity. Its effects can be thought of as similar to those of outsourcing. In the short term, it can lead to job losses and shifting opportunities. Those doing manual or repetitive tasks are often the first to be impacted; however the effects of automation can quickly spread to other areas. This can become especially problematic when those who are installing or maintaining systems become affected. Bringing in tools that would displace systems engineers can be challenging, as they may have a vested interested in seeing that the implementation is not successful. That’s why it’s critical that organizations understand how to properly make use of their workforce in a new, highly automated work environment.

Restructuring the workforce

Although automation can bring short-term job loss and dramatic shifts, it can also free resources to create higher level, more-rewarding jobs in other areas. As software and robotic systems displace their human counterparts, resources can be shifted to other departments. At the core of an effective automation implementation is an expert who knows how to minimize problems and ensure that human and autonomic resources are being used to their fullest extent. A robust management team also is needed to oversee external and internal services.

Cognitive Automation Primer

It is necessary, at least initially, to have staff who work alongside the automated workforce, stepping in to occasionally fix errors or address problems that are too complicated for the virtual engineers. This will, however shift as the system evolves. Autonomics allow the systems to improve their quality of service over time. Each time the systems deal with simple tasks, they amass more data in their knowledge repository, which they can later use to handle more complex problems. As virtual engineers become more sophisticated, the human workforce becomes less necessary.

[1] https://hbr.org/2015/06/robots-seem-to-be-improving-productivity-not-costing-jobs


WGroup has just released a new, 70-page ebook on Automation and Autonomics, entitled Cognitive Automation Primer: The World of Machine Learning. You can get your own copy of this comprehensive ebook at no charge by visiting http://www2.thinkwgroup.com/Cognitive-Automation-Primer.

Posted in Default | Comments Off on Automation and Autonomics – Effects on the Workforce

CIOs Increasingly Partner with Top Executives To Increase Business Competitiveness

by Michael Whitehead

CIOs Increasingly Partner with Top Executives To Increase Business Competitiveness

Technology must be a core facet of strategic business design for organizations to continue to grow, drive share and category. Technology-agnostic delivery models focused on the services delivered and business outcomes will, if deployed correctly, drive competitive advantage. The evolution of the CIO from information technology executive representing the business to business executive utilizing all components of technology to drive results, with disruptive technologies and a focus on transformation, not transaction, has never been more critical.

www.thinkwgroup.com

From technologist to technology representative and business advisor

Organizational transformation to meet the challenges of enhanced regulations, a rapidly evolving global customer base with unique generational engagement demands, and a continually morphing competitive landscape demands that a new perspective and engagement model be facilitated for the CIO. CIOs need to influence, and directly engage with the highest executive members including the board.

New customers expect technology focus

The past two decades have seen the information technology function immersed in delivering technology packages that essentially automate manual processes and deliver historical data about performance. Organizations have traditionally reported into the CFO and have been run as cost centers, with the CIO’s role focused on optimizing labor arbitrage while always seeking ways to do more with less. While this was happening the customer expectations and demands changed. Immediate gratification, personalization, an always-connected and always-on mindset, data and more data, peer influence, a social, mobile universe of opportunity have changed how consumers’ and workers’ viewpoints! In order to capitalize on this, innovative companies are realizing that their traditional approaches to technology will not work and that they must transform in order to survive in the long term. CIO engagement in this dialogue as a peer and influencer of strategy may be the biggest challenge the CIO has ever faced, but one never more critical.

Technology is now driving

An effective strategy has always been one centered around driving business value. Alignment of the technology strategy to the business strategy has traditionally been focused on enablement of an already defined business direction. One could possibly argue that this needs to be reversed with the technology strategy now being the catalyst that evolves into the business strategy.


WGroup has helped many CIOs assess and transform their IT strategic frameworks, governance structures, and operational processes to meet the sometimes competing demands of the business and emerging trends in IT. We adopt a pragmatic approach to implementing new IT capabilities that balances future needs with short-term improvements and benefits. Many IT transformations are designed to be self-funding, with subsequent phases exploiting the success of prior investments and improvements. Visit http://thinkwgroup.com/services/strategy-transformation/ to learn what we can do for your organization.

Posted in Default | Comments Off on CIOs Increasingly Partner with Top Executives To Increase Business Competitiveness

Agile-Based Project Management

by Israel del Rio

Agile-Based Project Management

Milestone targets will help reveal true progress – or failure

Many failed projects suffer from the same tactical mistake: doubling down on failure in the hope of a different outcome. This type of behavior has been well observed under the guise of the Gambler’s Paradox—continuing to gamble in the hope of recouping losses; resulting in even greater losses. Good project management, on the other hand, entails tracking down and detecting when a project is being derailed and then planning appropriate, timely remediation or even changing direction. This is why it’s best to properly partition a project into discrete and well quantifiable milestone targets. At least in this way, if something fails, it will only affect a portion of the effort.

Focusing less on micro-managing every activity and more on enabling the timely delivery of milestones that break-down the project into specific sub-projects is a more flexible approach.

Handling issues occurring at a sub-project level is less difficult. Also, having stand-alone milestones allows for possible early delivery of actual functionality. It is even possible to create some milestones to serve as a “canary in the mine”, as long as these milestones do not create unnecessary pressures or distract from the main path of the project.

Needless to say, the key to tracking and assessing the status and impacts of a project’s dynamic is the project management function. However, there is the mistaken idea that anyone with working knowledge of MS/Project can become an IT project manager. The fact is that in the world of IT, delivery managers with systems and software knowledge and background have traditionally been more successful in the project management role. Perhaps the reason for this is because this type of project manager is more able to assess the health of a project against actual milestone deliverables rather than via traditional Gantt charts with red-yellow-green status colors. This semaphore style might look good on status reports but does little to ascertain the true project status.

When establishing the project management governance, keep in mind that there are projects and, well, there are projects. Smaller projects have to be handled in a manner that assures the necessary ingredients for success are available to the team leader with a minimum of red tape. Smaller projects can benefit greatly from rapid application development methodologies1 and from early prototyping. In addition, smaller projects better align with the iterative approach favored by Agile methodologies. Partitioning a large project into smaller areas of work also facilitates the potential testing and introduction of innovative solutions while minimizing risks. However, partitioning should not be viewed as “fragmenting”. There is science and art in the way to partition a major initiative while maintaining a holistic and integrated view of the whole. In this sense, the principles followed in Agile development (planning game, small releases, simple design, etc.) also apply to milestone-based project management.

What defines a small project?

Well, having no more than five people working on a deliverable for a maximum of four months is as good a metric as any. If the cost of this type of project exceeds the one million mark including labor, hardware, and software capital costs, then it should not be handled as something small.

Then there are the medium size endeavors. These are projects that can take up to a year, or slightly longer if the powers-that-be are willing to take Prozac and give you a bit more leeway. The core development teams for this type of project should never exceed the magic number of twelve. These projects tend to fall in the ball-park figure of around two to three million dollars. A medium size project needs to be managed with a savvy combination of high-level project management controls and the appropriate placement of deliverable milestones.

Larger projects should not even exist. Why not? Well, a large project should be properly broken down into as many small and medium sized projects as possible. Ultimately, a large project should only exist in the PowerPoint® bullets of those responsible for your company’s public relations, in the minds of marketing (“Version 3 of our Super-duper product available by Christmas!”), and in the radar of the very small team responsible for the integration of all the various moving parts.

Clearly, the failed initial launch of Healthcare.gov was an example of a humongous project that was managed on a task-oriented basis. It had only one real milestone: Go into production by October 1, 2013. We all know what happened next. The story would have been turned out a lot differently if a milestone based approach had been followed.

So, what is agile-based project management really all about?

www.thinkwgroup.com

Basically, it’s the definition and tracking of measurable, well defined milestones. Note that we are not suggesting that the need to plan for tasks goes away; just that the project status should not be measured vis-à-vis the degree of task completion or the number of hours worked on a task, but rather against the milestone’s success or lack of thereof. Milestone management is based on outcomes as compared to the actual business requirements the project is attempting to solve.

The difference between a milestone and a traditional project management event is that the milestone should stand on its own as a visible deliverable. Visible is the operating word here. Completing a piece of code is not a milestone. Completing a working prototype or demonstrating a working sub-component of the deliverable are proper milestones. An eye-candy demo is not. If the event is something that can be shown to anyone outside the core development group, and is considered to be at least a partial success, then it qualifies as a milestone.

Tracking projects via milestones has a number of benefits:

  • Missing a milestone might be a clear signal that the project is not on track, but the impact of the delay can be contained in a timelier fashion

  • A successful milestone motivates the team by providing success checkpoints

  • Milestone deliverables with stand-alone utility can deliver actual benefits sooner

  • A successful milestone helps motivate the project sponsors to continue their support of the project even when faced with budgetary constraints

Conclusion

There is no way to sugar-coat a missed milestone. While this should not necessarily spell gloom-and-doom, a project with two or more missed milestones is a project that needs to be seriously reviewed and revised.

To be sure, it’s always best to allow room in a large project to anticipate the failure of a specific component and to adjust for the overall delivery because of this failure. The solution to this type of quandary might range from starting again from scratch (assuming the initial implementation was proven wrong), to completely eliminating the subsystem and remediating by providing a suitable minimum set of capabilities from other subsystems.

Ultimately, agile, milestone-driven project management will be superior to the traditional task-oriented project management style.


1 NOTE: Use of Agile methodologies should apply to the actual software development process; not to the architecture and design-making processes. Using pseudo-Agile approaches under the mantra of “code now, design later” often results in failure.


Keep on eye on your inbox or check back to www.thinkwgroup.com in mid-September to get your copy of the full white paper on Agile-Based Project Management.

Posted in Default | Comments Off on Agile-Based Project Management