Product Managers Unite!

Agile methodologies, DevOps practices and dedicated tools have improved collaboration, efficiency, and time to market for development teams. But the needs of product managers are often overlooked. Lenore Adam investigates Atlas in her first Micro Focus blog post, enjoy!

With dev, test, and biz teams, that is.  Thanks to a Micro Focus Atlas, product managers can now be at one with dev, test, and business teams.

Agile methodologies, DevOps practices and dedicated tools have improved collaboration, efficiency, and time to market for development teams. But the needs of product managers are often overlooked.

Capturing evolving customer needs and understanding the impact of these changes on schedules, resources, and budgets are what product managers do.  PMs are the voice of the customer for engineering, and the financial and business analyst for the executive committee.  But to do the job properly they need information in real time for insightful analysis.

  •  How will a new customer requirement impact the release cycle?
  • Which requirements caused the project timeline to slip?
  • How much development time was spent on a specific requirement?

This need for knowledge has driven the development of Micro Focus Atlas requirements management software. Let’s put Atlas to the test with a couple scenarios.

Your customers demand a new requirement. Development asks ‘exactly how badly do you need this?’

Product managers often have to evaluate trade-offs, like whether a new feature is worth a schedule delay.  They rely on data to support recommendations, but without good data, sound judgment is compromised.  One of my mentors used to chant ‘the data will show you the way’.  But how?

To begin with, you need your finger on the pulse of current activity.  Atlas creates a bi-directional link with DevOps and Agile tooling.  Customer requirements created in Atlas are sent to the Agile backlog, establishing a direct connection between customer requirements and the dispersed stories and tasks needed to execute that requirement. Automatic status updates of these activities are centralized back into Atlas and available for PMs. No black box of engineering activity, no need to interrupt busy engineering managers for updates.  Setting up the sync is pretty straightforward as these YouTube postings prove:

Syncing Atlas & Rally

Syncing Atlas & JIRA

Syncing TFS & Atlas

Now, with an eye on the future, use this data within the Atlas environment to develop a what-if planning scenario to evaluate options.  What would be the expected schedule impact if a new feature was included in the release?  Does the potential increase in revenue offset the expected schedule delay?  Linking engineering activities to customer requirements gives projects teams the tools needed to make better decisions.


So why did the schedule slip?

The execs promised the sales teams and customers a timely delivery. So what went wrong?  Feature creep?  Did specific features take significantly longer to execute than planned?

Use the Atlas Time Machine feature to clarify cause and effect.  Explain why the original estimate was so far off with historical tracking that summarizes which stories were added, removed, or updated and how this impacted schedule over time.

Leverage the data in Atlas for your project post mortem to make the next project even better.  Atlas project baselining is where the team hits ‘rewind’ to uncover the original project definition and scope. The version control identifies each change, the person who made it and any associated discussions for context.  For the multi-disciplinary team, this is an opportunity for an informed discussion and objective review after the whirlwind of development and release.

The hands-on executive – ‘hey, remember what happened the last time you did that?’ 

What happens when an executive bypasses the decision-making process?  Suddenly, a requirement ‘proposal’ becomes a new requirement, end of story.  True confession: we often padded our schedules and budgets with a line item affectionately labeled ‘friends of execs’ to factor in these unpredictable yet inevitable curve balls.

The trick is to view the schedule before and after the unplanned insertion in a previous project.  Was there a schedule slip – and if so, how bad was it?  Even understand the breadth of impact by using the Atlas Relationship Diagram to trace downstream requirements that may also have been impacted.

And here’s the killer data point you need to save the project from unhelpful top-floor intervention:  How much development time was chewed up by the requirement?  That said, Atlas just records the facts. You’ll need to draw on all your expert diplomacy skills to present them. Try ‘Just sayin’…’

Micro Focus Application Delivery and Testing   

Accelerated delivery.  Continuous quality.

Make Atlas your resource for uniting business, development, and test teams. And it doesn’t cost a cent to get started. Access a free cloud-based trial of Atlas 3.0 and start.

Take it Easy with Atlas 3.0

Atlas, our Agile requirements and delivery platform, has cool new features and Frank thinks you should hear about them. Needless to say, it reminds him of The Eagles.

Frank has been standing up for devs long enough to know that delivering complex IT projects can be heavy lifting.

It’s the complexity of pulling stuff together. Uniting guys in different siloes. Keeping everyone in the loop in a way they all understand. As usual, 1970s country rock can teach us a lesson from history. Take the Eagles’ recording of the Long Run album. Frank’s legendary freeform cassette stacking system reckons it was their last studio album for decades – and it’s not surprising.

According to producer Bill Szymczyk – Frank never loses a game of rock Scrabble, thanks to Bill – the band was so fragmented that they were phoning in their contributions from all over the States. Glen Frey – RIP, man – worked from LA while the rest of the band were in Miami. The result wasn’t great. And happened next? Acrimony. Lawsuits. Beverly Hills Cop soundtracks. And no-one wants that. So, thank the Lord for Atlas.

Third versions things aren’t always great. Waiting for the Sun had one single worth hearing. Jaws 3 had us all cheering for the shark. Atlas 3.0 is different.

Woah! What’s Atlas anyway?

Atlas is our Agile requirements solution. It unites key people in a beautiful oneness. Technical and operations teams get together with business analysts on a platform that captures market trends and innovative stakeholder ideas. It’s like getting the Airplane, Jimi and Janis in one place.


So. Atlas 3.0. Tell us more.

Atlas 3.0 now integrates with Silk Central. With this powerful test management platform in your locker, strategically planning testing suites, defining test cases and executing quality management just got easier.


Atlas and Silk Central integrations keep testing efforts aligned with customer requirements. Transparency and control are your new friends. Users view test activity and results in every requirement area. Integration ensures test teams can view – and test tools stay in sync with – defined requirements as they evolve.

Atlas 3.0: Frank’s list of good stuff

  • Review and evaluate the results of evolving business needs: See how requirement versions have changed over the life of the project. Changing course isn’t something you do at the end.
  • Assess potential impact of new requirements: Every picture tells a story. Use Atlas to create the diagrams that identify the interdependencies. It means smarter decisions – and more realistic schedules – around new requirements.
  • Improve collaboration between business and development teams: Communicate and exchange ideas and concepts as application requirements develop. It’s kind of the opposite of late-period Eagles.
  • Assess Agile team progress in the context of customer expectations: Is development time aligned with defined requirements? Get a clear picture with Atlas 3.0.
  • Show related test count and status by requirement. Understand how test execution has changed over time, providing visibility to incremental test progress.
  • View the test status as Gantt charts. Assess test progress across all requirements.
  • Step into the Atlas Time Machine. Better understand the impact of changes in requirements and evaluate project status, to see how test status has changed between two points in time.
  • Version comparison: Compare differences between two versions of requirements, or list the items that have changed since the last access.

You want this

Well, if you are a customer on maintenance it’s already yours, my friend. Rock up to Say Frank sent you.

Living in Non-Maintenance Palookaville? Fret not. You get to see how Atlas lightens the load by helping you gather, define, plan and track the agile delivery of your business needs, initiatives and related requirements. Try now. For Free.

Frank out.

Frank Profile

How does ‘David Moyes Syndrome’ relate to ‘legacy’ IT systems?

Put simply, David Moyes Syndrome is my attempt to put a name to the almost pathological urge that affects so many Premier league football clubs in a state of transition, namely the temptation to hit the panic button rather than take a more measured, strategic approach. The comparison stacks up, so bear with me…

Because clearly, Manchester United Football Club are a big business and it has been remarked that they are acting like any other organization with a strategic issue – although most companies rarely have to worry about losing to Olympiakos. (But then neither do many football clubs, for that matter.)

Initially, at least, the company are seeing immediate benefits for acting boldly. The club is a corporation where fans and shareholders alike demand sustained success. When that doesn’t happen quickly enough – and market share becomes eroded by rivals – they tend to act swiftly.

The same is true of banks and other companies with large IT estates. When their systems are perceived as lagging behind the competition, analysts and investors start asking some pretty fundamental questions. The crux is this: whether to scrap what is there and start again in the hope that the instant win keeps delivering, or choose a less traumatic, more strategic path.

For clubs like Manchester United, the landscape has been skewed by the arrival of unforeseen elements that could happen in any vertical. The wealthy backers of Arsenal, Chelsea, Manchester City  and Liverpool are raising the stakes and Manchester United feel compelled to respond. Where is their red-hot striker? Their resolute defence? More importantly, it seems, is their trophy magnet of a manager?

Likewise, to stretch the analogy, the presence of game-changing elements in the IT space is forcing businesses with older, more established applications and legacy systems to react to PayPal, eBay, Facebook, and Amazon. Customers are demanding a life online. They want to be mobile with constant connections to everything, everywhere – and that’s the context in which every company must now operate.

The arrival of a marketplace-distorting factor could happen anywhere, forcing the organization to raise their game in order to stay competitive. Indeed, some bank customers already use Facebook to make payments. So what can organizations do to avoid David Moyes Syndrome? Let’s look at the two options under consideration at United – revamp, or rebuild.


In footballing parlance, this is all about a new manager making sweeping changes to his playing staff. Out go X, Y and Z and here come 1, 2 and 3. A massive rip and replace IT project of this nature will arrive pre-loaded with large amounts of risk. It might work. It may not. You won’t know until it’s too late to do anything about it. Taxi for Mr Moyes.


But just like Manchester United, any organisation will have unique assets they risk losing by taking such a drastic step. Your company’s heritage is tied up in these systems. Lose them, and you risk some of your identity too. Your intellectual property is at risk. Isn’t it much better to make more of what you have? Adapt how you deploy your assets and introduce a couple of game-changers instead?

There are certain precautions available to mitigate some of this risk, at least. Just as the new United manager is likely to do, analysing what you have is as important as understanding the complexities you will need to overcome with these resources. So build your requirements from there and ensure everyone involved in the business has complete visibility of them. Get it right and you reduce the time to market significantly, perhaps gaining a march on the competition.

Micro Focus: game-changing software

Micro Focus understands the problem of making big moves in a risk-averse world. To us, modernization beats destabilization. The Micro Focus Enterprise product set tackles the application innovation modernization needs of IBM mainframe development and delivery teams. Our enterprise application knowledge, development, test and workload deployment tools significantly improve the efficiency of business application delivery, enabling IT leaders to transform their zEnterprise environment.

One way or another we’re all in a results business, so if you’re looking to stay in the race for the title, remember that before you succumb to David Moyes Syndrome, there are alternatives. Micro Focus development tools enable you to get more from your squad and deliver better results faster, without messing with the heritage of your organization. They also cost a lot less than paying off your ex-manager.



The Importance of the Business Analyst Role

By Chris Livesey, Vice President, EMEA & Latin America, Borland Solutions, Micro Focus

The Business Analyst role will be one of the most important roles in IT this year. It is a position that plays a critical role in deciphering the future for many businesses. To date the role has not been widely recognized as a profession in its own right – with other players such as finance managers, software architects and project managers being seen as taking the lead.

A Business Analyst acts as a bridge between business ideas and business capabilities; creating and scoping valuable changes and optimizations to business processes. Typically driven by conducting ‘performance capability assessments’, or ‘feasibility studies’, the Business Analyst regularly appraises business performance. Such reviews appraise capabilities ranging from  those visible to the customer through to those embedded deep in the manufacturing process.

Traditionally, in our technology driven business world, a large proportion of the changes and optimizations relate to software systems – and so teams in the organization responsible for creating, maintaining and delivering IT systems, are a primary focus. Conventionally, this has proven to be a difficult relationship, with challenging communication issues or mis-interpretations that often lead to wasted effort or scrapped projects. According to The Standish Group, this mis-communication can result in as much as 40% of the overall effort being wasted, on average.

Companies view quality as something that happens at the end of a project. This is classic ‘waterfall’ thinking – specify, create and then test. This has proven to be a poor approach. The success rates of projects working in this fashion are no higher on average than 40% (Chaos report, Standish Group 2011) – meaning missed end-client deadlines, issues with customer satisfaction and large amounts of wasted effort. A better mindset is “quality IS the work”. This culture and approach means that every part of the supply chain feels its own responsibility for the end result.

The Micro Focus Borland solutions enable Business Analysts to precisely and richly capture business requirements that are collaboratively shared with development teams. The development teams use these requirements directly to identify needs, relationships and priorities, within the business systems such that changes and optimizations are implemented in the most practical and efficient way possible. When standards and consistent approaches are used across the company, there is a greater clarity about how requirements are captured, documented and assessed, which ultimately leads to a far greater project success rate and a higher quality end-user experience.

High quality requirements drive software success – Forrester webcast

Forrester analyst, Mary Gerush, offers practical guidance for Requirements Definition and Management best practice. Highlights include the importance of good software requirements, the costs of getting it wrong and an overview of the tools available to help you get it right.

A Micro Focus webcast featuring Forrester Research, Inc. and Lockheed Martin.

Register to view and receive your FREE Forrester research report: Seven Pragmatic Practices to Improve Software Quality

Up to 70% of software defects are introduced during requirements gathering and design stages. Improving the quality of requirements has an immediate and dramatic effect on your project’s success. 

This exclusive webcast provides practical guidance on the steps to build in project success from the outset. 


  • Best Practice in Requirements Definition and Management: Forrester senior analyst, Mary Gerush, will discuss the importance of high quality software requirements, the costs of getting it wrong and the tools and best practices that will help you get it right.
  • Real-world experience: Bryan Fangman, Senior Systems Engineer at Lockheed Martin Enterprise Business Services, will describe the business impact of automating Lockheed Martin’s requirements definition and management processes with dedicated technologies for the job.
  • Requirements tooling that combine the best of both worlds: CaliberRDM from Micro Focus is the first requirements solution to combine support for requirements definition and ongoing management in a single web-based tool.

View now

If talk is cheap, surely that’s great news for software quality

Read our views on what 2010 will bring to the IT industry, and download your copy of the Gartner research note: ‘Predicts 2010: Agile and Cloud Impact Application Development Directions.’

Growth will return to the IT industry in 2010. Most industry commentators are in agreement on this, and so, while this is very welcome news, it is not actually tremendously newsworthy. Perhaps of more interest is the fact that such recovery is expected to take place alongside zero growth in IT budgets or employee numbers, placing yet greater pressure on IT to deliver what the business needs. So, if 2009 was about cutting costs and stripping out non-essential projects, 2010 has its emphasis placed firmly on the ‘more’ part of ‘doing more with less’.

To make matters worse, IT’s ability to deliver successful projects currently has its “highest failure rate in over a decade”, according to the Standish Group. And while Gartner figures suggest something less bleak, there continue to be enough high profile examples of failure and waste in IT to suggest that many will struggle to meet the needs of companies focussed on growth and profitability through the course of the next twelve months. In January 2010, one UK national newspaper reported that a “series of botched [Government] IT projects has left taxpayers with a bill of more than £26bn for computer systems that have suffered severe delays, run millions of pounds over budget or have been cancelled altogether.”

What We Have Here Is Failure To Communicate

In many cases, such as the UK’s £12.7bn National Project for IT, users were simply never consulted on “what they wanted the new system to achieve” or kept informed as projects rolled on and challenges arose. This is surely completely unacceptable and, what’s more, totally inexplicable. Especially when 70% of production defects are considered to have been created during requirements and design – not to mention that the costs associated with fixing these issues rise exponentially the longer they remain undiscovered. In a March 2009 paper on software quality, Gartner analyst Thomas Murphy quite understandably (and with some degree of under-statement) observes that this is a cause of “IT versus business friction.”

It is little wonder, therefore, that the tight linkages established in 2009 between IT spending and business performance metrics are considered to be here to stay.

With scrutiny and concern the order of the day, many of the industry analyst predictions that have appeared at the start of this new decade are focused on what IT should be doing to improve its success in the process of delivering quality software on time, on budget, and, perhaps more importantly, in line with the needs of the user.

The Beginning Of A Beautiful Friendship

Despite being cash-strapped and under-resourced , there are several factors that would suggest IT has reasons to be optimistic in 2010. Necessity has shown itself to be the mother, if not of invention, but of adoption. Organizations of all sizes are embracing new ways of doing things as they seek to break through yet another glass ceiling of productivity and cost-efficiency. One view, from Forrester Research, is that they need to start thinking like the “underfunded start-up that is always in the throes of a one-company recession.” It is not about working even harder than they do already. It is about working smarter. It is about working efficiently on the projects that matter, that drive revenue and growth. And staying close enough to the business along the way to know when priorities change and new goals arise.

It’s also about knowing when enough is enough, so that software no longer arrives bloated with redundant features that seemed like a good idea on the drawing board. Many companies find, as requirements are delivered incrementally and in line with business priority, that projects not only complete sooner, but the final 20% is often perceived as non-critical for deployment – and often never asked for again.

Such collaboration between all members of the software delivery team yields benefits for everyone. It creates what Thomas Murphy refers to as a “hive” mind set instead of being “adversarial”, where the different disciplines (such as business analysts, testers and developers) bring their respective strengths and viewpoints to bear on the problems being solved, helping to deliver software earlier in the project lifecycle and reducing rework.

You Had Me At Hello

In Gartner’s December 2009 research note, ‘Predicts 2010: Agile and Cloud Impact Application Development Directions’, the analyst firm draws attention to a number of ways in which IT can raise its game and deliver yet greater value to the business, with closer collaboration and the need for a broader definition of software quality very much at the heart of this.

Perhaps one of the most fundamental statements the research note makes is that “software quality can’t be tested at the end”. The IT horror stories mentioned earlier are living proof of this. Companies must look to drive quality throughout the development lifecycle and make use of facilities and processes that support this.

Agile development methods are already helping. They are driving (if not demanding) greater levels of collaboration. And the fact that these methods are now starting to take root in mainstream development shops is great news for lovers of quality software. Gartner believes that by 2012, “agile development methods will be utilized in 80% of all software development projects”, and, furthermore, that companies who embrace it, and introduce the cultural and behavioural changes to support it, are already seeing “four times the improvement in overall productivity”.

For IT to succeed in 2010, Vendors have a responsibility to provide not only the tooling, but also the process support to help companies drive quality from start to finish on a project, including helping them shore up weak requirement practices. By moving ‘quality’ upstream within the development process and linking it more closely with the beginning rather than the end of the lifecycle (for example, testing against user stories rather than function points), business and IT will understand each other more fully and improve their chances to share a common goal.

Only then will the growth that everyone is predicting, the growth that everyone needs, come to the industry on the back of fundamental, grass roots improvement, rather than through increasing the stress levels of an already stretched group of people. As an industry, it is time to grow up. Once and for all. It is time to talk.

Author: Julian Dobbins, Head of Analyst Relations, Micro Focus