Category: Home Page

Home Page

NHS green-lights Cloud

Home Page, Strategy

NHS green-lights cloud technology for storing patient data

NHS green-lights cloud technology for storing patient data

NHS Digital has issued new national guidance for health and care organisations considering cloud services for storing patient information.

The document outlines a framework for assessing and managing risk around the use of public cloud technologies in the health and social care sectors in England, including legalities around how data should be stored and used and considerations to be made by organisations when choosing a supplier.

The guidance also contains best practice principles for handling customer data and highlights considerations to be made by trusts prior to the introduction of the General Data Protection Regulation (GDPR) on 25 May.

The cloud has been widely embraced in other UK industries under the government’s 2013 ‘cloud first’ policy for public sector IT.

While some parts of the NHS already make use of the cloud – such as NHS Choices and NHS England’s Code4Health initiative – the publication of the national guidelines marks the first time the technology has been approved for widespread adoption within Britain’s health service.

NHS Digital said the guidelines would “enable NHS organisations to benefit from the flexibility and cost savings associated with the use of cloud facilities.”

Central to the policy is that cloud suppliers used by NHS organisations must host their data in the UK, or European countries that provide an adequate level of protection as agreed by the European Commission.

Cloud suppliers covered by the Privacy Shield in the United States are also deemed safe for use.

All vendors are required to use cryptography to protect communications and undertake annual security assessments against recognised standards, such as the International Organisation for Standardisation (ISO) or the UK Government’s Cyber Essentials. Suppliers must undertake regular monitoring procedures and keep customers up-to-date with any changes to the service that could impact the security of the IT system and data.

Further, Local Senior Information Risk Owners (SIROs), in conjunction with Data Protection Officers and Caldicott Guardians, must be satisfied with the security arrangements the cloud service provider being considered, using National cyber security essentials as a guide.

Rob Shaw, Deputy Chief Executive at NHS Digital, said: “It is for individual organisations to decide if they wish to use cloud and data offshoring but there are a huge range of benefits in doing so, such as greater data security protection and reduced running costs when implemented effectively.

“The guidance being published today will give greater clarity about how these technologies can be used and how data, including confidential patient information, can be securely managed.”

NHS Digital’s guidelines have been published in partnership with the Department of Health, NHS England and NHS Improvement.

They come at a time when NHS trusts are increasingly look to cloud as their next big IT project, allured by the technology’s promise of enabling rapid scaling-up without the associated hardware costs.

In a recent report from Digital Health Intelligence, a third of NHS surveyed said they were already delivering part of their infrastructure through the cloud, while 39% of the organisations said they planned to introduce some element of cloud-based infrastructure within the next two years.

In addition to lowering hardware costs and improving the ability to recover data in the event of a local system failure, it is argued that cloud technology could take strain off of overstretched GPs by giving them more freedom to work remotely.

From zero to PMO in thirty days

Home Page, Projects


Are your projects out of control? Is it difficult to determine the status of your most important projects? Is the status of all your projects “in progress?” Are the scopes of your projects in line with your strategic objectives? Are your estimating processes non-existent or totally dependent on a few key “experts?” Are you managing your resources effectively? Not even sure of what questions to ask? The maybe the answer for your organization is a Project Management Office (PMO) or if you already have one, then maybe you need a fresh look at your current one.

This paper will provide a 30 day plan for implementing a Project Management Office for your organization. Invest 30 days to provide a structure that can serve your organization for years. Continue reading “From zero to PMO in thirty days”

Key Steps to Implement a Project Management Office

Home Page, Projects

What Is a PMO?

A PMO is a centralised, co-ordinating body within an organisation (or project) that provides a focal point for the field of project management. It can identify and address project management issues to support and facilitate the achievement of organisational project outcomes.

What Are the Benefits of Having a PMO?

According to Gartner (2008), investments in a Project Management Office (PMO) as a work management discipline can provide common planning and reporting processes and bring structure and support to evaluating, justifying, defining, planning, tracking and executing projects. It also encourages the resolution of conflicts caused by limited resources and other constraints.

We’ve all seen renegade projects that seem to run according to their own agenda. A PMO can help organisations create effective control and oversight of projects and integrate them with the overall business outcomes. Continue reading “Key Steps to Implement a Project Management Office”

Process! That’s how we get things done around here!

Home Page, Projects

While virtually every leader professes to understand and believe in the importance of process, we know from client data that over 70% of all business problems relate to process deficiencies of some type. Most processes are undefined, complicated, not consistently followed, not measured, and loaded with non value-added activities. Leadership often reacts to these broken processes by adding reviews, approvals, and more complexity, while missing the underlying causes of performance shortfalls. When we press for details of leadership’s understanding, we quickly discover that many don’t know the basic process structure under their command and the essential customer – supplier relationships that exist in all organizations. Given this background, I offer following the essential reasons that all leaders should embrace process in running their organizations.

Why All Leaders Should Embrace Process

1. Process defines how work gets done.

A process is a series of tasks, events and decisions that consumes a product or service from a supplier, adds value to that product or service through some transformation, and then delivers a product or service of more value to a customer. Organization workflow consists of a series of business processes (e.g. Accounts Payable) that connects to deliver a larger business system purpose (e.g. Financial System). The further leadership gets away from the source of the work, the more likely leaders don’t know what’s actually happening on the front lines. It’s pretty common to hear a leader assure us that something isn’t being done when we know that it is. Continue reading “Process! That’s how we get things done around here!”

A digital transformation checklist

Home Page, Projects, Strategy

The market is filled with great insights on successful digital transformations. A recent report from McKinsey weighs the risks and benefits. Another, from MIT Sloan Management Review, compares digitally mature organisations with those still digitally adolescent. As with most adolescents, those less mature are noisier and messier, with the promise of better things to come!

Where should you start when assessing the opportunities and risks for your organisation? In particular, what are the balance points, for and against, digital transformation? What is the expected speed of any such change? How do you plan? (Can you plan?)

Here’s a high-level checklist — factors that influence success when driving a digital transformation:

Complexity v. Benefits: be clear about what you seek from a digital transformation for your organisation. Consider what such a transformation needs. Define the return on the investment and the effort you will expend in the transformation. Factor in how you might scale as you transform (and arrive at your end-state), and the infrastructure you need to deliver.

Architecture Speed v. Architecture Integrity: does it make sense that your organisation adopts the speed of a start-up? (Many seek to do exactly this when considering digital transformations, according to McKinsey). But can your organisation even consider this option? How should you balance system robustness and speed to market? Which is more important? What’s your appetite for risk, and how do you define what risk your organisation is prepared to consider in its systems architecture?

Predictability v. Flexibility: from which perspective do you wish to build your system architecture or data centre infrastructure? Do you want structured IT processes and systems that you own and manage, or a scalable public cloud that allows you to throttle up or down? Or a hybrid? What role will hyperconvergence and software-defined virtualisation play?

What to Keep v. What to Replace: Audit your existing IT infrastructure. Again, is it in-house, a “pure” cloud, or a hybrid? More-importantly, assess whether the cost and complexity of your existing infrastructure outweigh the benefits it delivers. Check how you quantify those benefits. Assess how much you spend simply on running hardware in data centres. (According to IDC, this can be as high as 80% of an IT budget.) If existing IT infrastructure has ended up in multiple silos, you’re ready for a digital transformation.

Accountability, Clarity & Visibility: how do you make the transformation team accountable for the project’s success? Include senior management, which is collectively accountable for the clarity of the vision, strategy and business case. Make everyone on the broader team accountable for the visibility of the project within the organisation (and therefore how well it’s understood and accepted).

Measurement: none of this is simple, so don’t seek a simplistic set of measurements. Reflect the complexity of the transformation in how you measure the project’s progress and success. Channel that complexity to track progress, highlight bottlenecks, test assumptions and benchmark performance. Be clear on how each of these interact with each other.

Financials: finally, explicitly link your digital transformation projects to revenues and profits. Be clear about how you expect to grow revenues, reduce costs, or enter new markets.

The primary goal of any digital transformation strategy should be the business benefits you seek to gain. Digital transformation should make your organisation faster in responding to opportunities or threats. Once established and clearly communicated, the readiness of your organisation to start and finish the transformation will follow.

Published on September 30, 2016 Sumir Bhatia Vice President, Data Centre Group, Asia Pacific at Lenovo.

MS Release Outlook Customer Manager

CRM, Home Page

Microsoft unveils a new, lightweight CRM for those not ready for Dynamics 365: Outlook Customer Manager

New service targeted at small businesses building better customer relations

It’s launched a new service and mobile app called Outlook Customer Manager that’s available as a free add-on for those with an Office 365 Business Premium Plan, starting today for those in the First Release program and rolling out worldwide over the next few months.

The app builds on Bookings, its customer scheduling app, and is designed to hit at the same small business segment.

“Outlook Customer Manager gives you a complete view of your interactions with each customer, helps you track tasks and deals in progress, and surfaces timely reminders. You can stay on top of customer relationships right from Outlook, with no need to install or learn separate tool,” Microsoft wrote in a release announcing the new software. “And as your business needs grow, you can move to Dynamics 365 to take advantage of enhanced customer information, process efficiency and consistency, and deeper financial and customer insights”

The app looks like a slick way to bring varying data sources — from calendar items to customer contact information — together in one place and allow smooth transitions in case one employee needs to hand off things to someone else.

On desktop, the application just surfaces as a new tab in Outlook (see above), and on mobile it has its own dedicated app:

The mobile app is iOS only for now, but Microsoft said it will be rolling out to other operating systems soon.

5 ways to think big, any day of the week

Home Page, Projects

“How do I make sure I’m thinking about the big picture, when I’m always working on a lot of small things that seem to take up all my time?”

This was a question a product manager once asked me when she felt lost in the weeds, and one you may have asked yourself. How can you empower yourself to step back and look at the big picture so you can lead your team more effectively?

Here are some highlights of strategies that have worked for me, and you might consider:
Allocate time to thinking
If you allow yourself to just do what’s next on your to-do list, you’ll never find the time to think about the big picture–there will always be something that feels more urgent. Block off time on your calendar based on when you’re most creative (morning, afternoon, evening).

Buddy up
Once you’ve allocated time to thinking, you’ll likely come upon a stumbling block: it’s hard to sit down and say to yourself, “Okay . . . think!” The best ideas often bubble up through the course of conversation, so it’s valuable to find another person to think with and bounce ideas back and forth.

If you’re in a management position, consider buddying with someone who reports to you: teammates who don’t often get the chance to strategize will be energized by the opportunity to do it with you. Through this exercise, your teammates will get a sense of ownership over the conclusions you come to together, while you’ll gain focus and clarity.

Choose specific goals
Unpacking your big-picture thinking into a handful of specific goals will make it that much more actionable. If you want to redesign your product, break down this ambition into more specific actions that have a finite timeline: For example, I want to write a draft for the product roadmap over the next two years, broken up into a hierarchy of themes.

Big questions are worth asking but they should be framed in a way that doesn’t feel burdensome or insurmountable. If they do, decompose them into smaller pieces until each one feels doable.

Identify first steps
Creating tasks in Asana with Due Dates and Assignees is how vision becomes action.

If I have big goal, I will generally procrastinate on tackling it unless I immediately choose the first steps. If I want to create a new product roadmap, my first steps may include finding all the various Google Docs and Asana projects where we’ve done roadmapping in the past. Next, I will read them. Next, I’ll make a list of potential features, then group those features into themes. Then, I’ll ensure there’s a specific deliverable and audience for the proposals. Having a time and a place when you know you’ll need to present your ideas (such as at a big meeting) to an audience is a good way to force you to structure your approach.

Ground yourself in reality
What are the big opportunities you’re actually able to tackle? Thinking big occupies a divergent brainstorming space–an alternate reality where there are no wrong answers. The last and most important part of this exercise is to move from the divergent space to one that is solidly based in reality. Be realistic about what options are actionable, and then take next steps. This is the convergent phase.

Encourage teammates to submit ideas onto a single project. Then, have everyone heart their favorites. Sort ideas by number of Hearts.

When followed up with action, regularly scheduled divergent big-picture thinking can bring new, better ideas to light, and give you confidence that the small tasks you’re doing all day are steps along the right path.

For starter ideas on how to think big on any project, check out the article in Fast Company.

Visit The Guide to get suggestions for using Asana to generate ideas, brainstorm, and turn those ideas into action.


Home Page, Projects, Strategy

The Project Management Office (PMO)Program and Project Management Offices (PMOs) have been in the news. OK, you won’t have read about this in your daily paper, but in the UK the PMOSIG became incorporated as the Association for Project Management’s 13th specific interest group a couple of years back. While PMOs have been around for a long time, this was a big step forward for the recognition of the work they do. And they do a lot more than just produce reports.

The role of a PMO

A PMO is the backbone of a successful project management approach at an organization. It is a function that provides decision support information, although it doesn’t make any decisions itself. A PMO underpins the project delivery mechanisms by ensuring that all business change in an organization is managed in a controlled way. According to the Office of Government Commerce’s, (based in the UK) standard for Portfolio, Program and Project Offices, the most mature PMOs provide:

  • Governance: ensuring that decisions are taken by the right people, based on the right information. The governance role can also include audit or peer reviews, developing project and programme structures and ensuring accountability.
  • Transparency: providing information with a single source of the truth. Information should be relevant and accurate to support effective decision-making.
  • Reusability: stopping project teams from reinventing the wheel by being a central point for lessons learned, templates and best practice.
  • Delivery support: making it easy for project teams to do their jobs by reducing bureaucracy, providing training, mentoring and quality assurance.
  • Traceability: providing the function for managing documentation, project history and organizational knowledge.

So what does that actually mean in practice? PMO teams fulfill a variety of functions on a day-to-day basis including:

  • Gathering data about project progress and producing reports
  • Developing standards and processes
  • Encouraging (or enforcing where necessary) the use of those standards and processes
  • Managing resources for projects
  • Delivering training and mentoring project team members
  • Managing dependencies across multiple projects
  • Tracking benefits
  • Reporting on financial information such as return on investment.

As part of this, the PMO is also the guardian of Enterprise Project Management tools and project management methods. There will normally be an expert (or several) in the PMO who can support project managers and their teams with using any project-related software.

Different types of PMO

PMOs look different in different organizations, as you would expect. A recent study by ESI found that nearly 60% of companies have more than one PMO, so decentralization is by far the norm.

Over a third of PMOs have more than 10 members of staff, and the location of the PMO is evenly split between IT, another business function and at a corporate level, so PMOs can be found pretty much anywhere in an organization.

In some companies, the project managers report directly to the PMO, although this is not as common as you might imagine. More than half of the project managers in the companies surveyed by ESI reported in to somewhere else. The increasing maturity of the PMO function means that we are likely to see more and more project managers reporting into a PMO in the future, which in turn provides a better opportunity for standardization and embedding tools and processes.

Your PMO might be a central function reporting to the Board, or it might be a department within a division. You may have a hub-and-spoke model with a central PMO and divisional units in different locations. The PMO might even be a temporary team, put together to support a large program. It may incorporate a centre of excellence for training and standards, or that might be separate. In short, there are a number of different ways for a PMO to operate, and they all have the objective of providing operational efficiencies and supporting the successful delivery of change.

Whatever model you choose for your PMO, getting the implementation right will undoubtedly make the difference between a function that increases the success of projects and one that just focuses on retrospective reporting. A mature PMO can really help an organization make the most of the tools, methods and the skilled staff they have, by ensuring all these resources are used in the best possible way to support the organization’s strategic goals.

This genius iPhone 7 case would give you back the headphone jack Apple removed

Home Page

Apple may have killed the headphone jack in the iPhone 7, but a new, sleek case is trying to bring it back.

“What people put into their own ear holes is a very personal choice, and it’s a choice we should all get the chance to make — not one that should be made for us,” Diego Prince, a hardware developer from Austin, Texas, said in a video announcing the cases, which would be made for iPhone 7 and 7 Plus.

Prince and his cofounder Troy Osinoff just launched an Indiegogo campaign, saying they plan to ship in December if the campaign reaches its goal. “Early Bird” backers can reserve one case for $49 plus shipping.

According to the campaign site, the Fuze takes the adapter dongle that Apple included with the iPhone 7 and builds it directly into the case, restoring the 3.5 mm headphone jack. It also has an extended battery pack and, as most cases should, protects the phone from damage if it’s dropped.

The battery pack would provide about extra eight hours of power, according to Prince.

The idea for the case is already getting plenty of positive feedback on Product Hunt, a site frequented by techies looking for the latest gadgets and software.

Prince is trying to raise $60,000 in the next month for Fuze, which he says will be spent on prototyping, testing, and shipping, with the goal of getting it to backers around Christmastime. But as with any crowdfunding effort, there are risks involved — namely that Fuze wouldn’t ship by its expected date, or at all.

Still, it’s an interesting concept that frustrated Apple fans may get behind.

“We do have an incredibly tight deadline,” Prince told Business Insider, though he said he is confident that he can deliver the cases on schedule.


Paul Szoldra

CIO: How to build your personal brand

Home Page, Strategy
As a CIO you have to carefully manage and nurture the perceptions that others have of you. By ‘others’ I mean internal staff and stakeholders, and outside of your company I’m talking about your peers, industry professionals, and thought-leaders. One of your key assets is your brand. Your brand expands upon more aspects of your character and your skillset than your job title, your CV and your career history. This article explains how you can build a brand that helps you to earn respect throughout your sector, and how the development of your brand can turn you into a sought-after personality in your marketplace.

Continue reading “CIO: How to build your personal brand”

Sync SharePoint sites with the new OneDrive sync client – Preview

Home Page, SharePoint
Applies To: OneDrive for Business
With SharePoint document library sync, you can sync the contents of a document library to your personal device. You can now do this with the OneDrive for Business Next Generation Sync Client.With this preview build, you can do the following:

  • Navigate into a folder or subfolder and click Sync. No need to sync the entire document library.
  • Change the folders that you’re syncing directly in the sync client.
  • Realtime coauthoring is supported with Office 2016 (C2R build 16.0.7167.2xxx or MSI build 16.0.4432.100x).

Continue reading “Sync SharePoint sites with the new OneDrive sync client – Preview”

Kotters 8-Step Change Management Model

Home Page, Projects

Leadership coach Susanne Madsen channels change management guru John Kotter to offer a method for effective change in your organisation. Here’s a shot of the whiteboard for your reference!

change management methodology

In Review

Susanne began by introducing us to John Kotter, a recognized authority on leadership and change. He developed an eight-step method to manage change, a process that she shared in the video. It goes as follows:

  1. Create urgency
  2. Form a powerful coalition
  3. Create a vision for change
  4. Communicate the vision
  5. Remove obstacles
  6. Create short-term wins
  7. Build on the change
  8. Anchor the change

It takes work, but anything of value does, and if you’re sure the change is needed then you’re invested and have the tools to see it through. 

Continue reading “Kotters 8-Step Change Management Model”

Your Legacy ERP Transition Is Rough:

AX, Home Page

5 Pain Management Solutions

Enterprise resource planning (ERP) solutions are costly to implement, with an average total cost of ownership around $4.5 million, according to Panorama Consulting. ERP’s break-even point ranges from one year to over five, with 35 percent of companies reaching this point by three years. These solutions are designed for long life cycles for profitability, but changes in technology infrastructure over the past decade create an environment where legacy systems hinder your productivity.

The Aberdeen Group found the average ERP system is seven years old. These legacy systems can put a heavy weight on a company, and even more modern customized solutions are moving into the legacy category as cloud-based solutions gain ground. You can’t eliminate the pain caused by moving from a legacy ERP solution to a new system, but you can manage it. Continue reading “Your Legacy ERP Transition Is Rough:”

AX7 post from Patrick Mouwen

AX, Home Page

I onboarded the AX7 technical conference this week with the impression that AX7 was ‘just’ a new UI exposing AX2012R3CU9 code on a new platform with some adjustments to ‘make it work’ on the new Azure platform. But already after the first keynote I felt embarrassed about my initial thoughts which quickly made place for respect and amaze for this enormous leap in technology.

I can only compare the way Dynamics AX has developed in the last 10 years with a boxing game: initially, the boxers tease and challenge each other by some quick targeted moves. But the game really takes off when one of them finds his ‘punch’ (say with the release of AX2012) The opponent is driven towards the corner of the boxing arena and receives punch after punch, each punch having bigger impact. I think AX7 is at the core of this ‘momentum’. In this blog I’ll share the main ‘punches’ and my personal interpretation of what’s going on. If you want to dig deeper then visit the publicly available AX7 wiki.

AX7: my top 12 highlights

1.       AX7 is a true Saas/Paas platform leveraging the Azure platform natively

In the literal words of Mike Ehrenberg, AX7 is not a ‘lift-and-shift’ of AX2012R3CU9: simply shifting the on premise platform to the cloud, as many competitors have done. Instead, Microsoft managed to separate the AX7 application layer and platform layer which allows AX7 to run on native Azure technology. So the many future Azure enhancements ahead will directly impact AX7 positively. With SQL Server, this was an exciting journey as only from CTP6 Microsoft was able to run SQL Server natively on an Azure VM.

2.       AX7 is Microsoft-wide achievement

When Steve Jobs and Bill Gates ignited Silicon Valley with their innovations, they could achieve a lot with a very small team of people. Now with AX7, the AX7 ‘pyramid’ is constructed from many already giant pyramids, ranging from SQL Server technology to Azure to BI technology. Each ‘pyramid’ has its own big team of experts. It’s amazing how Microsoft has managed to blend all these broad specialisms into the AX7 product.

3.       With the AX7 release is not incorporating new technology but driving new technology

With AX7 being a cloud-first platform fully in line with Microsoft CEO Satya Nadella’s focus for service orientation, The new Dynamics is now fully in the spotlights within Microsoft. Beyond that, AX7 is on a path where it drives the other Microsoft teams to enhance, instead of ‘just’ incorporating existing technologies in new releases. A good example is real time analytics. With the market demand for real-time analytics, AX had to move away from non-real time data warehousing and SSAS technologies in favor of the new read-only secondary database (replicated in seconds) and AX entity database (replicated in minutes). Instead, AX required new technology to allow true real-time analytics. This technology was found in new SQL Server 2016 in-memory technology, leveraging indexing on columns instead of the conventional row-based indexing.

4.       Enriching AX functionality exactly according to market demand

AX7 has been developed with more customer, partner and ISV involvement than ever. But that’s something that could have been done 10 years ago. The new thing here is that telemetry data is collected from actual AX7 usage. Based on already available data up to the recent RTW release, Microsoft has been able to identify exactly which areas of AX are used most and which areas have been customized most. This enables targeting all available development capacity spot on. Can you imagine what will happen if AX7 is enrolled to thousands of customers worldwide?

5.       The visible part of the iceberg is getting smaller

With the release of AX7, the production environment will no longer be accessible by customers or partners. Microsoft ‘frees’ the customers and partners from the responsibility to maintain this environment, to apply patches and – again in the words of Mike Ehrenberg – to allow the partners and customers to focus more on unleashing the potential of the software for their respective business instead of being bothered by ‘low-value’ activities. I prefer to use the metaphor of an iceberg in the water to express what is going on: the part of the iceberg which is really visible and tangible (the part above the water) gets smaller and smaller and the part under water bigger and bigger. In other words: less effort and ‘hassle’ against maximum value and service.

6.       AX7 resolves many implementation pain points

With AX7 Microsoft truly expresses an ongoing focus for shortening the AX implementation cycle. Many pain points are now solved by Microsoft:

  • Fast code deployment: the application code base has now been split up in multiple models. Code can now be compiled and deployed in smaller chunks and in a much faster way.
  • Easier code upgrades: the conventional ‘layering’ option is still there, but custom code can now be implemented as an extension (applicable to not all but many AOT elements). As such, the extension is completely segregated from the out-of-the-box code base, which makes customizations much more flexible, especially regarding future upgrade scenarios.
  • Shipping of configuration data among environments: with so called data packages (a collection of data entities which are an aggregated collection of tables and views), sets of data can easily be shipped across different environments. Optionally the data in the data package can be edited in Excel prior to deployment as the data package is physically nothing more than a zipped collection of Excel files added up with a header and manifest XML. So called ‘process data packages’ can even associate a data package with a specific process in the LCS process library. You can have a new sales order posted in a brand new originally empty environment in minutes.
  • Multi-purpose task recorder: the new task recorder can record tasks in AX not only to train people on any task in the software (including interactive guided clicking), but can also be used to automate testing. The recorded tasks (including the data captured) can be made part of new software builds to automatically regression test the build before deployment.
  • Retail: activation of a cloud-POS or mPOS device can now be done through an easy-to-use wizard. As there’s only 1 channel database for all your channels in the new cloud topology, the wizard preopulates the channel database URL and also the stores the device can be associated for (based on the Azure AAD user > worker > store address book > store association).

7.       Life Cycle Services (LCS) is no longer a recommendation but a requirement

In many ways adoption of life cycle services can no longer be avoided. Some scenarios to highlight this:

  • As AX7 no longer provides access to production environments, the telemetry LCS offers is crucial in identifying issues. Then consecutively, LCS is leveraged to quickly deploy a representative environment, load relevant reference test data and simulate the issue with a task recording.
  • Data packages and other assets are all stored in the LCS Asset Library. LCS is the central repository for storage and deployment across the various environments. LCS has a hierarchical structure: a ‘corporate’ section which allows re-using ‘assets’ among different projects.

8.       Support 2.0

AX7 re-defines the way you can support your users. Having your users record the issue they face through the task recorder is one thing. Being able to create a ticket from AX7 which is directly converted into a Visual Studio work item for the support engineer is another thing. But the earth shaking thing here is the available telemetry for the support engineer: as AX7 continuously logs system performance and system activity along the way, the work item is automatically enriched with a ‘snapshot’ of the state of the system at the time the issue occurred: what browser did the user utilize, what batch jobs were running, what was the user doing exactly etc.

9.       Business process orientation

Although I think the business process repository on LCS could be organized and incorporated in a better way, the AX7 UI offers a brilliant new way its application functionality is exposed to the business users: workspaces. Conceptually the workspaces have many similarities with the good old role centers: tiles are the new cues, tabbed lists are the old enterprise portal enabled listpages (although the new ‘tab’ structure is very handy) and charts and links can be embedded as role center offered (although far more sophisticated now). However, a user can now be offered a numerous number of workspaces, all supporting a specific set of tasks related to a process the user is affiliated with. The set of workspaces together forms the user’s dashboard.

10.   New features

OK, they might have become a bit less prominent because of the other hot topics mentioned, but AX7 still offers some great new features – a glimpse of the less prominent features:

  • Finance: cross company general journal entry: creating and posting journals without having to switch companies.
  • Retail: being able to download updates to mPOS from the device form directly (self-service installer). Process: a new update is made available by IT and a store manager can download and run the update package locally in the store.
  • Enterprise search and ribbon search: just type ALT+G to open enterprise search and then type “U C”. AX7 will come up with “Unit Conversion” immediately – one click and you’re in the form. You can even navigate to other pages by simply changing the URL. Type ALT+Q and you can search for a specific function in the ribbon, regardless of the tab group the function belongs to.

11.   The cloud: a new way of thinking

With the actual AX7 cloud release you have to be aware that basic on-premise functions have suddenly become a challenge. Here’s a shortlist of challenges and the way Microsoft managed to tackle those:

  • Accessing on-premise files and folders is not possible from the cloud: AX can no longer poll on-premise folders and pull-in files for processing, for example in recurring integration scenarios. Instead, files have to be pushed into the cloud. Here’s how: Microsoft has exposed an API which allows a source system to push a file into Azure blob storage accompanied by an enqueuing message which flags a recurring AX batch job that there’s a file to be processed. Microsoft will ship an application to do the enqueuing (and similar dequeuing for exports) on behalf of the source (or target) application. This application will be able to work with processing folders (IN, ERROR, COMPLETED etc.) as many customers were used to with the DIXF batch job (see this blog post by Kurt Hatlevik).
  • Printing on local network printers is not possible from the cloud. Again, we need an on-premise pull mechanism here. For this case Microsoft will ship a ‘document routing agent’ which will query an Azure queue for messages which contain meta data for new documents to be printed (stored in Azure blob storage). Network printers can be configured on a specific form in AX7 which will allow the Azure queue message to contain meta data which printer the ‘document routing agent should send the document to.
  • Hot keys: the different browsers have different reserved hot keys. To stay as much in line as possible with current hot keys users are familiar with, Microsoft had to be creative. For example, the ‘new record’ hot key CTRL+N has now been replaced by ALT+N, which is still pretty familiar for hot key addicts.

12.   Relatively low threshold for adopting AX7

It’s a challenge to develop and release a new product which involves so many paradigm shifts. But it’s pretty handsome if you manage to make the adoption of the new product still relatively easy – very important when it comes to minimizing costs for existing partners to make the shift and minimizing costs for customers to upgrade. Why I do consider the AX7 adoption to be relatively easy:

  • Developers will have to embrace Visual Studio, the AOT is re-arranged a bit and developers have to get used to work with the extensions and file based code and packages. But X++ is rather untouched (only enriched at some points) and for those who have some Visual Studio experience, a lot of ‘new’ things is actually common to .NET/Visual Studio in general.
  • Yes, the cloud environment requires a new way of thinking as stated in the latter point, but many things will be managed by Microsoft ‘under water’. As always, understanding the concept is much easier than having to become a specialist in an area.
  • With the earlier CTPs operating the new AX7 UI was a bit different than the familiar AX2012 navigation. But with RTW the similarities are very clear again. The area pages are back in town for those who worship them, form dynalinking (selecting a different record in the listpage is reflected in a details form) is working flawlessly and the good old ribbon and favorites are still there.

I hope this post inspired you to embrace the new AX7 features without any fear to make the jump.

Happy renewed DAX’ing.

SharePoint Co-authoring: It’s a date

Home Page, SharePoint

Ever been cursed with this pop-up?


On a Friday afternoon, right before close of business, when you need to get your TPS Report submitted to upper management, this can be the most horrifying message a computer can send you.

(Well, maybe just after the newly designed blue screen of death.)


And, oh joy, Word gives you three options: 1) save a local copy of what’s likely an outdated file, 2) get a notification when the person gets back (after the weekend, amirite!?),  or 3) give up all hope and press ‘Cancel’.

I can’t think of a better example of a lose-lose-lose situation.

So, why does this warning come up? Well, if you store a file—Word doc, Excel spreadsheet, PowerPoint presentation, etc.—in a shared drive or on older (or non-updated) versions of SharePoint, the system limits the number of editors to—you guessed it—one. (This is completely separate from the check in/out process in SharePoint, so don’t mix them up.)

And that’s the reason for this warning. It’s a courtesy (admittedly, that may be an overly nice term) meant to tell you that the file’s currently being worked on—or, more commonly in my experience: forgotten and never saved and closed—by someone else.

As if our lives aren’t stressful enough, I suspect this pop-up puts thousands on the brink of heart attacks every day. Thanks, Microsoft.

The solution

Because it can be a real nightmare to deal with this situation, Microsoft has finally introduced a service that allows you to edit files concurrently with your colleagues. And they call it co-authoring.

Basically, co-authoring allows multiple users to simultaneously edit the same document from multiple PCs. For the record, I hate this name. Because it’s totally misleading. But on we go.

If you’re familiar with Google Docs, concurrent/simultaneous editing has been available for years. So, for many of us, this functionality was a breath of fresh air when it was finally introduced in SharePoint 2013 and Office 2013.

Note, everything in this post relates to SharePoint 2013, Office 2013, and Office 365 (including SharePoint Online). If you’re looking for info on how Office or SharePoint 2010 or 2007 support co-authoring, go here.

I strongly suggest you push your IT department to upgrade if you’re still on these older versions of the software. And if you’re in IT, what’s the hold-up? Your users are waaaaaiting!

But how exactly does it work?

Hey, now that’s a really good question. Because the answer is far from intuitive.

Big picture-wise, it’s simple enough: essentially, you and your buddy Mike (Miguel, Mikhail, whatever) have the same Word doc open. Word tells you that you’re sharing the file with someone else. And you’re both safely editing the file simultaneously. In some instances you can see the edits occurring live in front of you, in others, you’ll see them once your application refreshes the content. If it’s live, you see a little cursor with the name of the person you’re working with. And it’s not just for Word. It also works for PowerPoint, OneNote, and, depending on the situation, Excel.


Coauthoring realtime


In actuality, it can be rather confusing, especially once you get into conflict resolution. And that’s why some people are deathly afraid of co-authoring. They feel they’ve lost control, that the domino was tipped before they meant to. On the other hand, many others have been wondering why it’s taken Microsoft so long to finally roll this out.

It’s an interesting dichotomy of user preferences, to say the least.

Co-authoring works differently depending on how you’re editing files. It depends whether you’re using Office Online/Web Apps (within your browser) or the actual applications (as in, launching MS Word and opening a document). I’ll refer to the latter option as the “client app” from now on.

It also depends on the app. Co-authoring doesn’t really make sense in some Excel files, so Excel offers limited co-authoring support.

What it does

You and your colleague(s) can open a Word, Excel, PowerPoint, or OneNote file and edit it at the same time. Big-picture, it’s pretty simple. The details, however… are not.

Knowing when you’re co-authoring

Sometimes it’s not the most obvious thing when you’re editing a file concurrently with someone else. Office will tell you, but you have to keep your eyes peeled. It’s way easier to tell if you happen to be on the same page, slide, or worksheet because you’ll see visual confirmation of changes. Otherwise, you’re dependent on little notifications elsewhere on the screen.

  • Using the client app (Office 2013):
    Client app coauthoring word
  • Using Office Online/Web Apps:
    Office Online Graphic


When you see updates

  • Using the client app: Whenever you save the file, any changes made by someone else while you had the file open will become visible. Your changes will also be uploaded and become visible to others. In essence, save = update.
  • Using Office Online/Web Apps: Updates are almost live, if you’re both editing through the browser. You’ll note a colored cursor that will display your colleague’s name. The color sticks to the user so you always know which changes are theirs and where they’re at in the file. Basically, update = automatic.
  • When using both: If you’re using Office Online and your colleague is using the client app, they will only see updates you’ve made once they save; likewise you will only see their updates when they save. (Basically, saving acts as a sync mechanism between the client app and SharePoint.)

If you’re editing with more than one colleague, anyone using Office Online will see instant updates made by other Office Online editors. Anyone using the client app will only see updates when they save, and the folks using Office Online will see those edits when they’re uploaded with the “save” from the client app.

Dealing with conflict resolution

I’ll cover this in a future post. It’s a topic unto itself.

Limits of co-authoring

Check out our infographic covering the size and usage limits for SharePoint. It has some info on co-authoring limits.

Coauthoring limits


How version history works

This one’s kind of tricky. Assuming you have version history enabled on your document library—because, remember, version history is disabled by default in a new library in SharePoint 2013—you should see the following behavior.

  • Using the client app: A new version is created every time you save the document. Whether it’s a major or minor version depends on the option(s) you or your site owner have chosen in the version history settings for that document library. In essence, save = version.
  • Using Office Online/Web Apps: Even though SharePoint automatically updates the file whenever you make a change when using Office Online—which is why there is no “save” button in Office Online/Web Apps—it doesn’t automatically create a version whenever it saves. Microsoft claims new versions are created every 30 minutes after someone begins making changes to the file. However, actual usage proves this to be inaccurate. Sometimes versions are made every few minutes, and usually the editor that’s “credited” with the version is the one who opened the file before anyone else jumped in. I have no idea why the tool acts differently than what their documentation says. But it definitely does.
    • In SharePoint Online (Office 365), you’re stuck with that time interval (30 min, even if it is inaccurate); in SharePoint 2013 on-premises, your IT department can change this. (Source) So, unlike using the client app, save ≠ version.
    • But! You can force-create a version by checking the file out and checking it back in when you’re done editing. Details are here.

Pro tip: you should brush up on how version history works, and what the differences between using major and minor drafts are.

Working with check in/out

Co-authoring and check in/out are mutually exclusive concepts. That said, you can co-author on a file that lives in a library where check in/out is enabled. But…

  • If “Require Check Out” is enabled on your document library, co-authoring is not available. (Source)
  • If check in/out is enabled (but not required), co-authoring can only occur when files are checked in. (Source)

I strongly advise not using check in/out if you want to make use of co-authoring. It just doesn’t make much sense to use both.

Excel and co-authoring

Excel doesn’t have the best relationship with co-authoring. In fact, in my experience, Excel doesn’t have the best relationship with SharePoint in general. This is a topic of its own, so I’ll publish a separate post on this topic in the future.

For best results, use Office Online

No, seriously. If you want to see changes occurring live, or just-about-live, you need to be editing the file in the browser. But, there’s a downside. A good amount of the functionality that you expect in the Office applications isn’t supported in Office Online.

Most notably, Track Changes is missing from Word Online. It’s just not available yet, which blows my mind because it’s kind of the most fundamental of collaborative tools.

Additionally, unless you’re working on a simple table in Excel, you’ll likely not want to use Excel Online: connections between worksheets and macros are just two examples of functionality that will not work in Excel Online (in fact, you get an error when opening these types of files). So while you may be able to see live edits being made, you’re going to be disappointed in every other way.

You can use the client applications, but the updates are delayed. At the rate that I save my files (not often enough), you could have written half of a book and I wouldn’t know it until I hit ‘Save’. Call me a bad user. But that’s a minor issue.


by Matt Wade March 31, 2016

Microsoft SharePoint vs Google Docssites

Google Apps for work, Home Page, SharePoint

I recently fielded a question from a potential client who wanted to know if Microsoft SharePoint or Google Docs with Google Sites was a better fit for their organization’s document management and collaboration needs. Although this question is pretty straight-forward, the explanation can get a bit complicated.

The short answer is Google Docs/Sites is great tool if you do not have an enterprise collaboration platform at your disposal, and you need to to get a document sharing site up quickly. However, Google Docs/Sites falls way short in providing the breadth and depth of features that Microsoft SharePoint offers.

SharePoint is a true enterprise platform with capabilities that extend beyond document management and collaboration (e.g. Search, Workflow, and KPI Dashboards. If you have a dozen or more computer users in your organization who need tools other than email and network drives to collaborate, you should strongly consider an investment in the SharePoint platform. Microsoft even offers a free version of SharePoint for small and medium sized organizations (less than a few hundred computer users), along with premium versions for larger organizations – sharepoint-deployment-planning-services.

Analysis Notes

Document Management

From a document management perspective, Microsoft SharePoint and Google Docs have compelling offerings. Both provide a browser-based user experience for managing documents in a central location and keeping track of a document’s version history.

SharePoint includes a wider variety of document management features than Google Docs, including:

  • Metadata tagging to help you organize and find documents quickly
  • Check-in/Check-out to prevent multiple users from editing a document at the same time
  • Document sets which allow a group of related documents to be treated as a single piece of content that share metadata and version history
  • Records management for managing the lifecycle of documents and providing for the ability to place documents into a legal hold state
  • Provides for the ability to trigger workflow processes (e.g. approval/publishing of content) whenever a document is added, changed, or removed

Google Docs may be a better fit than SharePoint in some circumstances:

  • Google Docs is quite a bit easier to setup and configure than SharePoint, so you should be able to get started in less time
  • Organizations with only a simple need to share documents may find Google Docs easier to use
  • Google Docs is often a good fit for organizations with ad-hoc teams that must be brought together quickly (especially when team members hail from different organizations)
  • Google Docs will likely cost substantially less to implement than SharePoint

If you are looking for a document management solution that supports day-to-day employee and interdepartmental document sharing as well as special projects, then SharePoint will be a better fit for your organization in the long-run. If you just need a quick and dirty solution for an ad-hoc project, then Google Docs is probably a better way to go.


SharePoint and Google Docs with Google Sites are pretty far apart on the maturity scale – SharePoint has been around for over 10 years and is a pretty stable solution for the Enterprise; Google’s Docs with Sites were released less than 4 years ago which is evidenced by a few bugs that bite from time to time.

Both SharePoint and Google product suites include document management systems and the ability to create collaboration sites, but SharePoint includes quite a few additional features. SharePoint is often referred to as a Swiss army knife of collaboration and office productivity features.

Feature Comparison

SharePoint features that are absent from Google’s offering include:

  • Flexible collaboration site templates and structures provide the ability to meet varying business needs of different departments and teams
  • Workflow to automate and manage business processes
  • Enterprise search capabilities to index content on your network drive (as well as the content you store inside SharePoint)
  • Configurable lists to capture metadata when storing documents
  • Centralized task lists to replace spreadsheets (great for managing projects)
  • SharePoint dashboards can integrate data from other systems to track your Key Performance Indicators
  • Tight integration of Documents, Tasks, and Calendars with the Microsoft Office Suite (e.g. updates made in Outlook, Word, Excel, and PowerPoint will automatically update the central copy inside SharePoint)

Permission Management

SharePoint and Google offerings also differ significantly when it comes to permission management. Google has limited permission management, allowing you to only define who can view content and who can edit content on each site. In SharePoint you have a lot of flexibility regarding the granularity of permissions – within a SharePoint site you can allow people to view some of the content, but not all. Similarly, you can allow people to modify some pieces of content, but not all content. Permissions are also easier to maintain in SharePoint. Access rights for Google Sites and Google Apps are maintained separately, which can sometimes overlap and lead to some confusion or surprise over who has the ability to access or edit content.

Market Share

The organization adoption level for Google sites is pretty tiny when compared to the adoption level of SharePoint. Google Docs had a few notable customers switch from MS Office (Word/Excel/PowerPoint) to Google Docs, but Google Sites hasn’t really taken off yet.


Overall, SharePoint is still a category killer and the clear winner when it comes to document management and collaboration solutions. For good reason, there are over 100 million users of SharePoint world-wide!
Originally Posted by Rick Rietz

Three Steps to Issues Management

Home Page, Projects

Issues are large problems that are impeding the progress of the project. Issue Management is the process of identifying and resolving issues within a project. By quickly and efficiently managing issues, you can:

  • Limit the effects of unforeseen events on the project
  • Reduce the time spent administering project issues
  • Greatly improve your chances of project success

You can complete the issue management process by taking three simple steps:

Step 1: Identify the Issue
Any member of the project team may identify a new project issue. An is completed to describe the issue and its impact on the project. The actions required to resolve the issue are also identified.
At this point the Project Manager also needs to determine who needs to be involved in resolving the issue.

Step 2: Investigate and Prioritise the Issue
The Issue Form is then forwarded to the Project Manager, who investigates the issue and determines the overall issue priority. The priority of the issue is determined by its impact on the project’s ability to achieve its stated objectives. If the issue is severely impacting the project, then it is assigned a high priority.
When determining the issue priority, the Project Manager considers whether the:

  • Deliverables listed in the scope are affected
  • Quality targets are affected
  • Schedule end-dates are affected
  • Resources are affected
  • Budget is affected

The Project Manager and project team need to recommend the actions to take to resolve the issue.

Step 3: Resolve the Issue

The Project Manager takes the issue, and the recommendations for resolving the issue, to the people that need to resolve the issue.

  • These people were identified earlier.
  • These people need to make a decision on how to resolve the issue.

The Project Manager is then responsible for scheduling and implementing these actions and reviewing the issue on a regular basis to ensure that it has been resolved accordingly. Throughout the Issue Management Process, the Project Manager can monitor and control issues impacting the project by keeping the up-to-date.
By completing these three steps for each issue that arises, you will be able to minimize the effect that issues have on your project and thereby increase its chances of success.

How to Plan in an Agile Environment

Home Page, Projects

Have you ever heard something like: “Agile development expects that we can operate quickly, efficiently and effectively without necessarily having an overall strategic plan”? If so, forget it! Why? Try to build a house from the roof and see what happens!

Detailed planning is as essential to the effectiveness of Agile as it is to Waterfall. The difference between the two approaches lies in timing. Planning is ongoing in Agile, and its incremental approach allows projects to adapt rapidly to changes. Planning is predictive in Waterfall and the client knows exactly what to expect.

Predictive vs Adaptive Projects

Predictive projects are the ones in which the needs are not likely to change (at least we wish that they don’t change) and where the work being done can be “somewhat” identified and measured. Adaptive projects are those where requirements are likely to change – frequently in some cases – and the work is largely creative with high levels of uncertainty.

Categorize the Project

How can we correctly categorize our project? Here are some questions to guide us.

  • Do we have requirements not well understood in advance and that are likely to change over the life of the project?
  • Do we have a domain not well known in all its details?
  • Are our teams trying to solve problems where the solution requires invention?

If we answered positively to the preceding questions, we’re probably facing with an adaptive environment; we should try to get an Agile approach to manage that kind of project, and the reason is that Agile provides the needed feedback mechanism to deliver adaptive projects.

How Much Will it Cost?

Okay, we decided to manage our project using an Agile approach. At the first progress review meeting, the management wants to know, “How much will it cost and how long will it take?” Organizational resources need to be allocated to the project. We need to provide feedback at a number of levels to answer the initial set of questions to ensure we are still delivering the best value for our organization’s investment. To effectively answer and satisfy our management, we need to provide them a plan.

Doing the Right Work and Doing the Work Right

In the initial phase of the project, when it’s not a real project but just an initiative to be funded, portfolio and program planning are needed to “do the right work”; in this phase planning is a high-level activity used to decide which initiative deserves to be funded.

When the initial filter has been passed and the initiative has been funded, the detailed activities provided by the analysis of the requirements has to be planned and this is about making sure that the team delivers against the product vision to provide business value on an iterative and incremental basis.

The Product Vision

The product vision is a really strategic means that clarify to the team why they are working, what they are working on and what key constraints they must work within. The vision is often detailed in a “Project Charter” document.

As an advice to get an “effective” charter, write it down with the whole team in a collaborative workshop with the project sponsor and product owner present. If the team members who will work on the product are not in the office, let’s get them together for the workshop in order to create a “one team” culture (it’ll be good also as a team building exercise).

If we get someone onboard after the vision has been created, let’s provide him/her a complete “training” using the project charter as a guide to help him/her understand the drivers behind the work being undertaken.

Typical contents of the project charter include:

  • Problem/opportunity description
  • Why should we deliver this project? What’s the value for our organization?
  • How does the project align with the organization’s strategic goals?
  • What are we trying to deliver? – let’s provide a high level solution description
  • Key features of the product that we’re going to deliver
  • Assumptions – where appropriate – and constraints
  • Scope – what’s included and above all what’s excluded from our responsibility?
  • Key timelines to deliver
  • Budget and cost-benefit analysis
  • Subordinated and/or related projects – let’s provide the key milestones of our project for alignment with those projects
  • Risks with mitigation actions – where appropriate

There are some techniques that can be used to organize the “collaborative workshop” that will produce the product vision. A few are listed below:

The Elevator Statement

The “elevator statement”, also called the “elevator pitch”, is something that will enable any team member to explain the purpose of the project (a statement composed by a few sentences to explain the goals and objectives of the project) in the time it takes to ride between floors in an elevator (imagine you get into the elevator with the CEO of your company and you are asked to explain what the project is you are working on before the elevator gets to their floor).

Business Benefits Matrix

A simple matrix which articulates the strategic value that the product is intended to provide. The matrix looks like the following table:

business benefits matrix

There should only be one primary driver and there might be a number of secondary or tertiary goals. Where there is more than one goal in a column then they need to be ranked to avoid the “everything’s critical” conflict.

If we got this matrix filled up as a group activity, we’d help the team to understand the focus for the project.

Scope Matrix

We could use a simple “in/out list” to define what will be done, not be done and where there is uncertainty about deliverables. When we place an item in the “in” column, we state that the team is responsible for its delivery. When we place an item in the “out” column, we state that the team will not spend any time or effort on it.

When we are uncertain about an item being in scope or not, then we place it in the “undecided” column and the project manager needs to investigate further to identify if the team have to place it in the “in” or “out” column.

The Product Roadmap

At the beginning of our initiative we have to produce a product roadmap, a list of the most important features that the product will deliver to address the scope. Of course if we expect to deliver just one release of the product, the product roadmap will coincide with the release plan.

The product roadmap is a high-level plan maintained by the product owner and the project manager that is expected to change over time and is validated against the product vision (let’s remember to plan also the validation events).

The Release Plan

The release plan consists in the list of features that we’re going to deliver in the next release of the product. Of course the features included in the release plan are the ones that the product owner and the project manager agreed to release based on the prioritization made at the level of epics and stories.

A release consists of a number of iterations during which the team will deliver measurable value to the organization.

Stories and epics need to be sized (in story points or ideal days) and prioritized so that the work can be allocated to iterations.

Let’s see how this happens:

  1. The product owner clarifies the goals for the next release.
  2. The team discusses the needed features to address the goals.
  3. The team discusses all factors that can influence the goals including risk and dependency between epics and stories. High risk-high value features should be taken home earlier than the others in order to easily adapt whether the risk evolves into a problem.
  4. We plan the activities based on the team’s velocity. We could use an estimated initial team’s velocity as the starting point for planning the activities. For planning the activities for the next releases, of course, we should use the actual velocity and not the estimated initial one (unless the team changes significantly between releases). The simplest approach to guess the initial velocity is to ask our team members how many story points they think they can deliver during an iteration and plan based on that number. It will probably be wrong, but it could be a good enough starting point. 

Once we have the estimated velocity, it’s time to plan the iterations:

  1. List the stories and epics for the release in priority order with their size.
  2. Decide how many story points we can deliver in a single iteration – please consider the impact of idle time used for example to prepare the tools needed to work.
  3. Add an iteration to the plan.
  4. Add stories to the iteration till reaching the maximum capacity.
  5. Share the plan and ask for feedback to get the highest commitment.

Let’s remember that the release plan is an adaptive plan and will change whenever we need.

The Iteration Plan

Every Agile team should be able to plan the activities included in an iteration based on the lessons from the work done in the previous iterations. They use the iteration planning to validate the release plan and produce the detailed iteration plan.

We should organize one or more sessions of iteration planning to analyze the release plan and update it based on any changes happened since the last update.

Changes could happen, for example, due to:

  • velocity of the work delivered in previous iterations;
  • priority changing in stories or epics; 
  • introducing new stories and epics (e.g. as a result of a new risk identification); or
  • recovering idle time that reduces the team’s ability to complete tasks.

During the first part of the meeting, the product owner explains the actual priorities and the team revises the iteration plan for identifying the stories to be done in the actual iteration.

The amount of stories included in the actual iteration will be based on “yesterday’s weather”, that is the team’s velocity based on the amount of work done in the previous iteration.

The reason behind the choice of establishing the velocity based on the amount of time needed to complete the previous iteration is that it’s very likely that the team will complete the same amount of work as they did before, unless they have been changed a lot or the working environment has been changed significantly.

The second phase of this meeting will consist in breaking the work down into specific tasks to be “pulled” by every team member during the next iteration, based on his/her ability to do the task in the amount of time initially estimated to complete it. Let’s keep the tasks’ size very small – from a few hours to a day or so.

Now it’s time to allocate the tasks and confirm the commitment of all team members and this is the due of the “iteration manager” (in Scrum he/she is the Scrum Master).

Let’s write the tasks down onto cards (e.g., colored post-it) and hang them up on a large and visible surface (e.g., the wall in the open space where the whole team can see it).

Let’s provide the team with an Iteration Backlog on which all members can find the stories and epics included in the actual iteration.

We could track the progress of all the tasks on a grid placed on the same wall where we placed the task cards. On the grid we could write down the task, who is responsible for completing it, the estimated time to complete it, the remaining hours to complete it and the actual hours used to complete it (so we could measure if we are late or not on our schedule).

The last grid should be completed by every team member to track his/her work against the tasks and represents their daily commitment.

To check our progress, we should use the so-called burn-down chart that is a graph showing the initial estimate and the remaining effort for the iteration.

The burn-down chart can be used by the team to try to improve their estimation skills in the next iteration planning meeting.

The “Daily Standup” Meeting

Daily meetings are the most important and effective tool used for communicating the progress within the iteration. Every day the whole team gets this meeting and the iteration manager asks the status of all tasks assigned to every team member.

There are a few simple rules to be taken into account and strictly followed by each member.

  • It is held standing up and the maximum duration is 15 minutes (can you afford a standup meeting held for more than 15 minutes? Let me know if you can afford it every day…)
  • No more than one minute for each member to expose the status of the task assigned to him/her.
  • No deviation from the actual story / task and the status can be “Done” or “Not Done” – it’s not valid to say “I’m at 75%”; in that case, it’s “Not Done” and the member has to declare how many hours he/she needs to complete it.
  • If a member has any obstacle to pass, he/she will declare it on a separate basis after the meeting.
  • Each team member answers just to the following questions:
    • What have you done yesterday?
    • What will you do today?
    • What’s in your way? (“Nothing” means you’re going to complete the tasks respecting the estimated time without any expected obstacle.)

The iteration manager is responsible for removing all the obstacles declared by the team members (after the standup meeting) so the team can be fully productive.

Just one last rule: we have to keep in mind that we shouldn’t punish our team members for not meeting task commitments because otherwise our task force will adapt to the behavior and won’t tell the truth about the status of the tasks during the standup meeting.

We have to consider that sometimes we will estimate badly or something will happen that prevents someone from working on their task but that isn’t a bad thing, it should be a motivation to improve our skills.

When planning in any methodology you’ll want a tool robust enough to cover all the bases, including monitor that plan and then reporting on it. That’s where comes in. Its online and collaborative suite of software provides a project leader with the tools to do the job. Try it yourself with this free 30-day trial.

MoSCoW Prioritisation

Home Page, Projects

10. MoSCoW Prioritisation

10.1 Introduction

In an Atern project where time has been fixed, understanding the relative importance of things is vital to making progress and keeping to deadlines. Prioritisation can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests. MoSCoW is a technique for helping to understand priorities. The letters stand for:

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have this time

The reason we use MoSCoW in Atern is that the problem with simply saying that requirements are of High, Medium or Low importance is that the definitions of these priorities are missing. Using MoSCoW means that priorities are specific. The specific use of Must, Should, Could or Won’t Have implies the result of failing to deliver that requirement.

10.2 The MoSCoW Rules

These are some possible definitions of what the different priorities mean. It is important to agree the definitions with the users. Preferably this is agreed before the requirements are captured – i.e. before it becomes emotive.

10.2.1 Must Have

These provide the Minimum Usable Subset (MUS) of requirements which the project guarantees to deliver. This may be defined using some of the following:

  • Cannot deliver on target date without this
  • No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
  • Not legal without it
  • Unsafe without it
  • Cannot deliver the Business Case without it

Ask the question, “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, simply that delivery is not guaranteed.

10.2.2 Should Have

  • Important but not vital
  • May be painful to leave out, but the solution is still viable
  • May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.

A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.

10.2.3 Could Have

  • Wanted or desirable but less important
  • Less impact if left out (compared with a Should Have)

10.2.4 Won’t Have this time

These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritised Requirements List where they help clarify the scope of the project and to avoid being reintroduced ‘via the back door’ at a later date. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.

10.3 Ensuring effective prioritisation

10.3.1 Agreeing how priorities will work

Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won’t Have need to be agreed with the business. Some examples are described above. However, the Must Have definition is not negotiable. Any requirement defined as a Must Have will have a critical impact on the success of the project. The Project Manager or Business Analyst should challenge requirements if they are not obvious Must Haves; it is up to the Business Visionary or their empowered Business Ambassador to prove a requirement is a Must Have. If he/she cannot, it is a Should Have at best.

Agree escalation or decision-making processes, e.g. Business Ambassador to Business Visionary to Business Sponsor, and agree the level of empowerment around decision-making at each level.

\At the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the next increment. This means that, for instance, a Could Have that is unsatisfied in an increment may be demoted subsequently to a Won’t Have, because it does not contribute enough towards the business needs to be addressed next.

10.3.2 The Business Sponsor’s perspective

The MoSCoW rules have been cast in a way that allows the delivery of the Minimum Usable Subset of requirements to be guaranteed. Both the team and those they are delivering to can share a confidence in this because of the high degree of contingency allowed in the delivery of the Must Haves. A rule of thumb often used is that Must Have requirements do not exceed 60% of the effort. If this rule is followed, then that ensures contingency represents at least 40% of the total effort.

So is this all that the Business Sponsor can expect to be delivered? The answer is an emphatic “No”. Whilst understanding that there is a real difference between a guarantee and an expectation, the Business Sponsor can reasonably expect more than this to be delivered except under the most challenging of circumstances. This is where the split between Should Haves and Could Haves comes into play.

If the Should Haves and Could Haves are split evenly with 20% of the total effort associated with each then the Musts and Shoulds, in combination, will represent no more than 80% of the total effort. The remaining 20% of effort associated with the Could Haves is now the contingency available to protect the more important requirements. By most standards this is still a very reasonable level of contingency and rightly implies that the Business Sponsor can reasonably expect the Should Have requirements to be met. It is just that, quite understandably, the team does not have the confidence to make this a guarantee. So, sensible prioritisation, combined with timeboxing leads to predictability of delivery and therefore greater confidence. Keeping project metrics to show the percentage of Should Haves and Could Haves delivered on each increment or timebox will either re-enforce this confidence, if things are going well, or provide an early warning that some important (but not critical) requirements may not be met if problems arise.

10.3.3 MoSCoW and the Business Case

The best way to address prioritisation initially is with a quantified Business Case. This should support Feasibility and be revisited during Foundations. If a Business Case does not exist, the Business Sponsor and Business Visionary need to articulate the business drivers, preferably in a quantified form. Some practitioners believe that any requirement contributing to the Business Case should be defined as Must Have, others accept that a small reduction in benefit is unlikely to make a project completely unviable and desire a more pragmatic solution. These practitioners believe that it is sensible to allow the requirements contributing to the Business Case to span Must Have and Should Have requirements.

Figure 10a: MoSCoW and the Business Case It is likely that contractual relationships (whether formally between organisations or informally within an organisation) will influence the decision on this issue one way or the other.

10.4 Levels of priority

MoSCoW prioritisation is really only meaningful in a specified timeframe and the same requirement may have a different priority in that context. A Must Have requirement for the project as a whole may not be a Must Have for the first increment. For example, even if a Must Have requirement for a computer system is the facility to archive old data, it is very likely that the solution could be used effectively for a few months without this facility being in place. In this case, it is sensible to make the archive facility a Should or a Could Have for the first increment even though delivery of this facility is a Must Have before the end of the project. Similarly, a Must Have requirement for an increment may be included as a Should or a Could Have for an early Development Timebox. Many consider this approach to be sensible as it allows the more important requirements to be addressed earlier rather than later but, if taking this approach, beware the risk of confusion. Each deliverable effectively has two or even three priorities in different timeframes and the Project Manager needs to ensure that the team do not lose sight of the real business priorities. The best way to deal with this is to create a Timebox PRL, a subset of the Project PRL that is specifically associated with a timebox and leave the priorities unchanged on the main PRL for the project.

10.5 What to prioritise

Every item of work has a priority. Priorities are set before work commences and kept under continual review as the work is done. As new work arises either through introduction of a new requirement or through the exposure of unexpected work associated with existing requirements, the decision must be made as to how critical they are to the success of the current work using the MoSCoW rules. All priorities should be reviewed throughout the project to ensure that they are still valid.

10.6 How many of each priority?

When deciding how much effort should be Must Have requirements, bear in mind that anything other than a Must is, to some degree, contingency. The aim is to get the percentage effort for Must Haves (in terms of effort to deliver) as low as possible and to be wary of anything above 60%, i.e. 60% Musts Haves, 40% Should Haves and Could Haves. Won’t Haves are excluded from the calculation, as they won’t be part of this project/increment/timebox. Levels of effort above 60% for Must Haves introduce a risk of failure, unless the team are working in a project where estimates are known to be accurate, the approach is very well understood and the environment is understood and risk-free in terms of the potential for external factors to introduce delays.

10.7 Hierarchies of priorities

Requirements are identified at various levels of detail, from a high-level strategic viewpoint (typically at Feasibility) through to a more detailed, implementable level (typically during Exploration and Engineering). High-level requirements can usually be decomposed and it is this decomposition that can help resolve one of the problems that confront teams: all requirements appear to be Must Haves. If all requirements really were Must Haves, the flexibility derived from the MoSCoW prioritisation would no longer work. There would be no lower priority requirements to be dropped from the deliverables to get the project back on time and budget. In fact, this goes against the whole Atern ethos of fixing Time and Resources and flexing Features (the triangles diagram).

Believing everything is a Must Have is often symptomatic of insufficient decomposition of requirements. A high-level Must Have requirement frequently yields a mix of sub-requirements, each with a different priority. Flexibility is once more restored and some of the detailed functionality can be dropped from the delivered solution so that the project deadline can be met. Where a requirement has a Must Have below a Should Have for example, this would signify that if this requirement were to be delivered, it must have the lower level requirement to be acceptable.

10.8 Tips for assigning priorities

  1. Work closely with the Business Visionary to ensure they are fully up to speed as to why and how Atern prioritises requirements.
  2. Start all requirements as Won’t Haves and then justify why they need to be given a higher priority.
  3. For each requirement that is proposed as a Must Have, ask: “What happens if this requirement is not met?” If the answer is “Cancel the project. There is no point in implementing a solution that does not meet this requirement,” then it is a Must Have requirement.
  4. Ask: “I come to you the night before deployment and tell you there is a problem with a Must Have requirement and that we can’t deploy it – will you stop the deployment?” If the answer is “yes” then this is a Must Have requirement.
  5. Is there a workaround, even if it is manual? If there is, then it is not a Must Have requirement. Compare the cost of the workaround with the cost of delivering it, including the cost of any associated delays.
  6. Ask why is the requirement needed – for this project and this increment.
  7. If there is a Business Case in sufficient detail, can it be used to justify the intended priority? If not, create one.
  8. Is there more than one requirement implied in a single statement? Are they of the same priority? Decompose the requirement!
  9. Is this requirement dependent on any others being fulfilled? A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of it not being there.
  10. Allow different priorities for levels of acceptability of a requirement. For example. “The current back-up procedures will be followed to ensure that the service can be restored as quickly as possible.” How quick is that? Given enough time and money, that could be within seconds. They may say that it Should happen within four hours, but it Must happen within 24 hours, for example.
  11. Can this requirement be decomposed? Is it necessary to deliver each of those components to fulfil the requirement? Are the decomposed elements of the same priority as each other?
  12. Tie the requirement to a project objective. If the objective is not a Must Have, then probably neither is the requirement relating to it.
  13. Remember that team members may cause scope creep by working on the fun things rather than the important things. MoSCoW can help avoid this.
  14. Does the priority change with time? For example, for an initial phase, it is a Should Have but it will be a Must Have for the second increment.
  15. Prioritise defects/bugs, using MoSCoW.
  16. Prioritise testing, using MoSCoW.
  17. Use MoSCoW to prioritise your To Do list. It can be used for activities as well as requirements.

10.9 Summary

MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) is primarily used to prioritise requirements, although the technique is also useful in many other areas. Atern recommends no more than 60% effort for Must Haves for a project, with 40% Shoulds and Coulds. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.