From zero to PMO in thirty days

Home Page, Projects

Abstract

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.

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.

10 Tips For Giving Effective Virtual Presentations

Me, Projects, Strategy

What to know before you go live.

An illustration of a computer screen with messy notes and graphs around it.
Presenting online? Try these suggestions to improve your results. | Illustration by Tricia Seibold

As audiences go global and you need to reach more people through technology (including webinars, conference calls and teleconference), you must consider the challenges to connecting with a virtual audience. Here I pinpoint 10 valuable best practices to ensure you communicate successfully.

1. Be Brief

Audiences begin to lose attention after roughly 10 minutes of hearing from the same presenter. If you have more than 10 minutes of content, use interactive activities to keep your audience engaged (for example, take a poll, give quizzes, or ask audience members for their opinions via chat).

2. Be Simple

Keep slides simple — avoid too many words, graphics and animation features. Less is definitely more!

An illustration of a lamp
Light yourself well | Illustration by Tricia Seibold

3. Be a TV Personality

Look straight into your camera, not the screen. Wear clothing that is neutral in color (no plaids or stripes). Light yourself well and from above. Be mindful of what appears behind you in the background. Invest in a good microphone.

4. Be Standing

Even though your audience cannot see you, stand when you present. This allows you to stay focused and use good presentation delivery skills such as belly breathing, vocal variety, and pausing.

5. Be Prepared

Practice delivering your presentation with your technology in advance of your talk. Make sure all of the features of the technology work. Record your practice using the recording feature of your tool. Watch and listen to learn what works and what you can improve.

6. Be Assisted

Have someone available to deal with technical issues and to field email/text questions. Also, if you have multiple remote audience members in one location, be sure to pick one of them to be your “eyes and ears.” Ask them to queue up questions and facilitate discussion on your behalf.

7. Be Specific

Ask pointed questions to avoid too many people answering at once. For example, rather than ask, “Are there any questions?” try “Who has a question about the solution I provided?” Set a ground rule that people state their names prior to speaking.

An Illustration of two pictures of people.
Imagine your audience | Illustration by Tricia Seibold

8. Be Synchronized

Transitions are critical. You must connect what you just said to what is coming next when you move from point to point. Transitions between topics and slides are good opportunities to get people reengaged to your talk.

9. Be Connected

Imagine your audience even though you can’t see them. You can place pictures of audience members behind your camera so you can look at people as you present.

10. Be Early

Encourage your audience to access your call or webinar in advance of the start time so you can iron out any technical issues in advance and get them familiar with the technology.

September 26, 2016|by Matt Abrahams is a Stanford GSB organizational behavior lecturer, author, and communications coach.

WHAT DOES A PMO DO?

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.

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”

ERP Implementation – The Traps.

CRM, Projects
Published on May 6, 2016 Vinay Bansal

ERP implementations are littered with tales of lost millions and withdrawals after implementation. Many of the most experienced IT consultancies/ Software Providers have failed. So what are the secrets? What are the traps? This question could produce at least a book, and probably a sequel. Here are a few things the Software Provider is not going to tell you about. They are by no means the most important, but they are missed in many implementations.

ERP Systems

Most organisations do not understand the costs associated with an ERP system when they first commence the implementation. The benefits are usually well understood. The costs do not surface until well into the implementation – and why should the Software Provider talk to an organisation about the costs and difficulties when they are trying to make a sale?

On the surface, there are very attractive reasons for going ERP. Benefits include:

  • A single system to support rather than several small and different systems
  • A single applications architecture with limited interfaces
  • Access to management information unavailable across a mix of applications
  • Access to best practice systems and procedures
  • More integration hence lower costs
  • More “automation” of tasks Generic Costs and Impacts

The costs and impacts are understandably not played up by the ERP Vendors. Some of those are:

  • Implementation effort will be bigger then ever talked about or even imagined. We are yet to hear from an organisation who have implemented ahead of schedule and under budget.
  • Because of the richness of functionality, the “toy box effect” can take over. Users see all the functionality available and suddenly they want it now. The scope can grow out of control.
  • The existing environmental mix between what is done manually and what is done by the system will swing dramatically after implementation. Many more tasks will be automated. Automation will significantly reduce the flexibility of how you operate as a business.
  • Users need to become more computer literate. Many see this as personally challenging – even beyond their ability – and will not cope, or leave the company.
  • The word “Enterprise” in ERP means that whatever happens in one area has a ripple effect in other areas. Understanding the implications of actions of one area, on other areas of the company, is not something that happens overnight. Training tends to focus on how do I do my job. It should also focus on what are the impacts of my job, in other areas.
  • Near enough is no longer good enough. Data integrity becomes critical. The computer cannot make human judgments. If stock is moved, it is no good somebody remembering where they put it. The information needs to be put into the system or there will be a domino effect. E.g. Stock is moved from location A to location B and the information is not put into the system. The system will tell someone to get the material from A and when it is not there, they have to go looking. At the same time it is telling someone else to put new material in B, but B is full. The first person finds the original material in B and logs it into the system. We now have double the quantity in the system again and it doesn’t reorder. And so it goes on and everyone is blaming the system.
  • ERP systems tend to replace old systems. As such it is a quantum leap for all areas of the company. It is replacing the trusty Ford with a high performance Ferrari. This happens at a Technical level as well as a Business Level. New ways need to be learnt in a very short space of time.
  • Things have to be done consistently. No longer are we able to do something one way in one branch and another way in another branch. The system is going to determine how we do things in all locations. Even within one location, special treatment may not be possible any more without changing the configuration of the system. If the system says you can either have 0, 15, 30 or 60 day credit terms, you can no longer offer 45 day terms without changing configuration. If consistency can be implemented, there is good potential for cost savings as well as getting rid of special arrangements that reduce profit.

 

Corporate Culture

All the points above contain technical issues or business issues which can be managed if they are identified soon enough. Training can show people the impact of their actions in other areas. QA programs can focus on quality of data. What most managers who have been through an ERP implementation, will tell you, is the biggest impact is on “Corporate Culture”. It is always underestimated and never overestimated.

Corporate Culture is a combination of two things.

  • The type of people who are employed by a company. Their personal values, skills, habits etc.
  • The way the organisation works. The focus, decision making process, attitude to staff, stability, etc.

Both feed off one another. Job applicants who feel aligned with the way the organisation works and comfortable with the style of person who interviews them, will likely get the job, and perpetuate the Culture.

To successfully take on an ERP system, an organisation needs to change it’s “Corporate Culture”. · It may need to change from being highly flexible and not paying a lot of attention to consistency or accuracy, to one of being almost obsessed with detail. · Of being prepared to have Business Practices that are actually adhered to rather than just being documented and forgotten. · People need to change from focusing on turnover to focusing on profit. ERP makes profit far more measurable down to Department, Customer and Material level. ·

Staff need to change their focus from their own job, to the whole organisation. What they do in their area has impacts in places they may never have envisaged. None of this is easy, and in many cases will be unachievable. Some people will not be prepared to make the change and will either leave of their own volition or be asked to leave. This is the cost of ERP.

Another dimension to “Cultural Change” is the timeframe in which the change is to be made. It basically needs to happen over a few days. One week you can bend all the rules and get away with it; next week the system will not let you. No matter how much training and preparation takes place, it cannot prepare many people for reality. That is not to say the preparation should not take place. The preparation will ease the pain, not take it all away. The more preparation the less the pain. On the positive side, some people will take to the system like the proverbial duck to water. These people tend to be (but not all are) younger, newer employees who have had experience in other organisations. They know the benefits of a good system and are frustrated with the current one. They will jump at the chance to make use of the new technology.

 

Change Management

Change Management is about setting expectations that lessen the pain of change. People involved in a change expect to go from A to B. Perhaps where they are actually going is to C. Change Management is about getting them used to the idea that C is the real destination.

To give an example, any new system is bound to have teething problems. If users expect that all is not going to run smoothly on day 1, and that they may be working back late for the first week because of problems bedding in the new system, they are less likely to reject the system when it does go wrong. On the other hand telling staff that this is going to be a great new system with no problems can only lead to disappointment and rejection when bugs appear. As such, change management is measurable.

Measuring attitudinal changes is not a complicated process. Properly managed, we can see how people feel about the changes over a period of time, and how they shift in their expectations. The results of money spent on change management can be seen. Not putting in the effort before implementation, will cost an organisation after implementation. What is the cost to an organisation of a system that is forced upon people, and with which they feel little ownership? They will either sink it, or ensure it never reaches it’s potential. Either way, the organisation will never get the return on investment it imagined.

Other experiences.

A survey of organisations that have implemented ERP’s was carried out recently. It identified “10 Common Causes of Disaster”.

  • Change Management and Training.

    This was mentioned as the major problem with implementations. Changing work practices to fit the system is a major difficulty. Also mentioned were training across modules and starting training sooner.

  • To BPR or not to BPR

  • It is difficult to draw the line between changing Business Processes to suit the system or retaining Business Processes and paying the cost, in dollars and time, to change the system. As time and cost squeeze the implementation, the usual path is to not modify the system, but to change the way people work. This feeds back into Change Management and Training.
  • Poor Planning

    Planning covers several areas such as having a strong Business Case, to the availability of Users to make decisions on configuration, to the investing in a plan that captures all the issues associated with implementing it.

  • Underestimating IT skills

    As most people are upgrading from old technology, the skills of the staff need to be upgraded as well. The upgrade is also going to place significant demands on a team who are geared to maintain an old but stable environment. Usually this effort is underestimated.

  • Poor Project Management

    Very few organisations have the experience in house to run such a complex project as implementing a large-scale integrated solution. It usually requires outside contractors to come in and manage such a major exercise. It can be a fine line between abdicating responsibility and sharing responsibility. Many consulting firms do a disservice to their clients by not sharing the responsibility.

  • Technology Trials

    The effort to build interfaces, change reports, customize the software and convert the data is normally underestimated. To collect new data, and clean the data being converted, will also require an effort that is beyond what is normally expected.

  • Low Executive Buy-in

    Implementation projects need Senior Executive involvement to ensure the right participation mix of Business and IT, and to resolve conflicts.

  • Underestimating Resources

    Most common budget blow outs are change management and user training, integration testing , process rework, report customisation and consulting fees.

  • Insufficient Software Evaluation

This involves the surprises that come out after the software is purchased. Organisations usually do not do enough to understand what, and how the product works before they sign on the bottom line. The Bleeding Edge ERP is so massive and integrated that reporting and linking to other systems (either your own or your customers and suppliers) can be much more difficult than you expect. Companies looking at ERP need to examine how they accept online feeds from a customer, or a customers’ customer, and examine the technological enablers as well as the implications of these technologies inside of the Business.

Summary.

All this leads to a list of likely problems with an ERP system.

  • The cost is likely to be underestimated
  • The time and effort to implement is likely to be underestimated
  • The resourcing from both the Business and IT is likely to be higher than anticipated
  • The level of outside expertise required will be higher than anticipated
  • The changes required to Business Processes will be higher than expected.
  • Scope control will be more difficult than expected
  • There will never be enough training – particularly across different modules

Most important of all, and the single biggest failure point for ERP implementations, is the need for change management. The need for change management is not likely to be recognized until it is too late. The changes required to corporate culture are likely to be grossly underestimated. It is going to be hard enough to cope with the technical issues without having to address major people issues as well.

Simple service request process

Projects

In smaller projects, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. Here’s a process that can be used for each request.

It stands to reason that smaller projects don’t need the same level of project management discipline as larger projects. With a small project, it’s easy to define the work, easy to manage the activities, and there usually isn’t much work associated with managing risk, quality, communication, scope, etc.

In many organizations, a simple service request process is used to manage these small projects. This service request process starts off by defining the work to be done on a simple one- or two-page form — aptly enough called a “Service Request” form.

The process for assigning the work is different as well. When the work definition for a larger project is completed, the project is usually ready to begin. However, for smaller efforts, there may be many more Service Requests than can actually be worked on at any given time. Therefore, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. The following Service Request Process can be used for each request:

Client submits the request. The client completes a simple Service Request form that documents the work requested.
Project manager review. The project manager reviews the Service Request to ensure that the work is understood. The project manager asks questions of the client if necessary, to clarify what is being requested.
The effort, cost and duration are estimated. The project manager provides a high-level estimate of the effort hours, duration and cost, and adds this information on the Service Request. (If the project manager can’t estimate the work, they assign to a team member to create the estimates.) When the work is actually assigned, a more detailed estimate can be prepared if necessary.
The request is assigned or backlogged. The project manager and client evaluate the request against the other work that is assigned and on the backlog. They also review the available capacity and skills on the team to determine if the work can be started immediately. If the required resources are not available, or if the work is of lower priority than other Service Requests, the new request is placed on a backlog list.
Periodically review the backlogged work. The project manager and client review the backlog on a regular basis, probably weekly or bi-weekly. During this review, requests on the backlog should be reprioritized. When the priority of a Service Request is high enough and the right resources are available, the work can be assigned to begin.
Revalidate the initial information. When the work is assigned to begin, the person(s) doing the work should validate that the information on the Service Request is correct and that the estimates are accurate. If they aren’t, the new information should be documented and discussed immediately to see if it will have an impact on the priority.
Execute the work. The actual execution of the work begins. This would follow a typical short lifecycle for a small project.
Manage the work. Since the request is small, the project manager will manage the work as needed.
Close the work. When the work is completed, the client should signify their approval. The Service Request should then be moved to a closed queue that tracks these requests for historical purposes.

 

By Tom Mochal | August 2, 2005

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 ProjectManager.com 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.

Microsoft Dynamics, the real ERP alternative to SAP

CRM, Home Page, Projects, Strategy

Last Thursday 19th of November, Microsoft gave at last more details about its new Microsoft Dynamics Ax and since them we can start giving more details about this new revolutionary ERP platform. Cloud based (but later alter mid 2016,  also On-Premise), modern HTML5 interface based on Office 365 look and feel, Power BI, Real Time Analytics with On Memory Database Technology, Office 365 & CRM Integration, Machine Learning and much more.

This new version present a huge leap in technology but maintaining the proven functionality that have helped thousand of companies along the world to optimise their processes and continue operating in a more challenging and more interconnected economic world.

The objective of this post is to focus how Microsoft Dynamics compares to SAP. The other big player on the  ERP market who is still dominant for implementations in big companies, specially in their homeland Germany where they have still about 50% market share and worldwide about 20%. That means a lot of new customers for Microsoft Dynamics when they get the opportunity to see that Microsoft Dynamics offers much more for their money.

Apart from other soft reports you would see out there, I can report from own experience. I work on the Microsoft Dynamics world since more than 8 years and I am actually based in Germany where I have contact with lots of companies that uses SAP but also I had an intensive experience with the new SAP version S/4 HANA with Fiori in the last 6 months.  Even I was in the SAP central in Walldorf to take part in an official SAP HANA course 🙂

I want to focus my comparation on several points. On the Cloud, the development experience, the BI platform, the On Memory database, the functionality, the availability of professionals and formation possibilities and last the qualitity of the IT partners.

Cloud platform

With the arrival of Satya Nadella, Microsoft took the courageous way of betting for the cloud, at that time Cloud was considered still a Hype and only companies like Salesforce and Amazon were at the forefront of innovation on the cloud. This all changed and since 2010 Microsoft is innovating on the Cloud building its Microsoft Azure with an extense geographical presence allowing customers to have their data near their operations. Even in countries like Germany it is provided a german only cloud with the colaboration of local partners like T-System.

Products like Office 365 and Microsoft Dynamics CRM are a huge success  and the pace of innovation it is quite impresive  but it doesnt mean that Microsoft presents a incoherent set of products because all of then are easily accesible from the main Microsoft Azure platform. Even casual developers can start playing developing web/mobile applications with technologies like Machine Learning and Big Data with only a single account and maybe not to expensive fees after the free account expires. This is specially important because you build a developer community that gives exponential innovation.

SAP cloud offer is based, mainly in the purchases of another companies like Ariba, Concur and Fieldglass. These are great products but it is absolutely not a homogeneous set of products giving confusion to the customer. SAP it is also building their datacenters and providing more an more their business solutions on the cloud which have damaged fees from products on premise but this year they are almost doubling the cloud business from the numbers of last year. As developer you can also start playing a little with HANA on the cloud developing web applications but it still languishes behing the developer community build by Microsoft.

Development experience

The development experience with SAP from the point of view of someone that comes from a world of modern programming languages is a horror story. With the new Microsoft Dynamics Ax you will develop your business code with X++ and some task with C#. Everything from a unique development platform,  Microsoft Visual Studio. Developing in Microsoft Visual Studio is just a pleasure because of the productivity of the tool, their options and the nice look and feel.

Instead developing business applications for the new SAP S/4 on HANA implies to learn ABAP, XSJS, Java, SQLScript HTML5, CSS and Javascript and to use  several development IDES like ABAP Workbench, ABAP Development Tools for Eclipse and SAP WEB IDE. Just learning ABAP is a nightmare and the language itself is a obsolete language that comes from the first versions of SAP. ABAP was at it early stages only a language used for reports and because of the back-compatibility it involved in a procedural language and last in a object oriented language in an artificial way. It first name was already “Allgemeiner Berichts-Aufbereitungs-Prozessor”, which means something like general report processor. There is always a rumour that SAP would like to kill ABAP but it is still there on the last version SAP S/4 because almost all the business logic is builded with ABAP. That forces the developer to learn how to develop with OData in order to build interfaces between the logic, the new database and the new HTML5 based interface. Obviously the developer have not very extra time left to think about developing business code when he has to spend too much time so much languages and interfaces.

When you are a Microsoft Dynamics Ax developer you have inmediately access to all the info you need to be productive. All the database tables and business classes are pretty well documented. Just try to google CustTrans on Google and you will get access to the Microsoft Site on MSDN where the table is descripted. Just try to make the same with SAP, to find out, which table contains the customer transactions and maybe you will spend quite a lot of time just to try to find basic info.

Last about the development of user interfaces in the last version of Microsoft Dynamics you just have to know about one technology, HTML5. And everything could be made with only drag&drop and coding on the events and on the methods for the form object on Visual Studio. There is no need to be a WEB geek in order to develop business applications on the Cloud.

Meanwhile with SAP you still have to learn to develop with the old Dynpro, maybe Web Dynpro, maybe SAP PERSONAS, and last with FIORI. Setting FIORI to start working it is also not a work for novices and require a not so easy configuration. Last, developing for FIORI is it not the easy task that SAP tries to sell you. You will have to go much more on the HTML details but also build the interface with OData between the business code and the ABAP code. That in case the business code is in ABAP, because is the business code is in HANA nobody, even most of the SAP professionals, doesnt know still where the hell would be the business code.

BI platform

Microsoft BI offert for Microsoft Dynamics implies the cool new Microsoft Power BI and the new services from SQL SERVER 2016. That´s it! Just take a look at the new Power BI and you would be impresed. On behind will be powered with an On Memory database that will deviler results in light speed.

On the other side with SAP you will find a myriad of products and offers that makes not easy to understand which one do you have to use. Some of then are more apropiate for the managers, anothers for your department leaders and finally others would be more appropiate for the shop-floor. So you will have to choose between SAP Lumira, SAP BW, SAP Crystal Reports, SAP BusinessObjects Web Intelligence, SAP BusinessObjects Explorer, SAP BusinessObjects Dashboards, ….

This is absolutely not easy but also not cheap!

On Memory database

In the field of On Memory database maybe SAP have the advantage with its HANA database. Now Microsoft with its SQL SERVER 2016 seems to be serious about On Memory and this is the main reason because Microsoft Dynamics Ax would be only available on Cloud until mid next year. Microsoft have to wait until the On Memory technology available on Azure it is available for On Premise systems. It that case I would recomend big companies with million of transactions per day to ask for a realistic perfomance test of both platforms in order to decide. If HANA copes better with such a huge amount of data it could still makes sense to spend so many money in a complicated platform like SAP. In another case, if you dont process millions of transactions per day you are trying to kill a flea with a sledgehammer.

Functionality

The new Microsoft Dynamics Ax comes with not to many changes on the functionality, that it is important because the functionality that comes from Microsoft Dynamics Ax 2012 R3 it is already proved and not too many changes are needed. That it is a little like SAP that maintain its functionality given in modules like MM, SD, FI, CO, MCM and develop industry solutions based on that.  Allmost all the functionality provided by SAP it is included in Microsoft Dynamics. I can also say that on german if that sounds more professional for you: Lieferbeleg erstellen, Materialen Kommissionieren, Warenausgang buchen, …. everything it is available in Microsoft Dynamics Ax to implement your processes in the most optimal way.

One curious thing about SAP implementations it is that your company it is supposed to work the way that SAP dictates in its implementations. Even on the analysis phases of a SAP project the users are simply presented some SAP powerpoints about the functionality and the users have to present their GAPs. That could be good in cases of companies that doesnt have clear how they have to work or optimize their processes but if you have a clear view of your company and you  want to be ahead of the competition you will need much more. An example of that company is Inditex in Spain (Zara stores). They have build their own system using no standard software because they are a step ahead of the rest and adapting to processes thought by others would make then slower. But that is a radical option that no everybody can implement. Microsoft Dynamics Ax presents a flexible solution that you can adapt and that will grown with you. Obviously making changes to the system without understanding the standard functionality is also not a very good idea.

Availability of professionals and Formation possibilities

It is report that SAP consultants in Germany could make almost 100.000 € and developers even reach the 80.000 € mark. That it is only a hint of how expensive would be your SAP project if you choose SAP. To become a SAP professional almost the only way is to take part on the expensive courses at SAP due to that the system and it myriad of options it is quite innacesible for the casual guy. Even if you work on a End User it would be not very easy for you to learn to use the system without some SAP support. There is some initiatives from SAP like OPEN SAP but most of the courses doenst offer more than just marketing of new technologies.

To become a Microsoft Dynamics Ax Developer you doesnt need too much requirements. It is enought to be a .NET developer with some SQL Skills to make the ladder. Once you have the option to play with a system at an End User or at a Microsoft Partner you can learn quite fast if you have the right colleagues with you. Microsoft provides also on its Customer Source and Partner Source plenty of formation documents and if you wish you can also attend some of the official Microsoft Courses which will speed up your skills on the products.

So I dont see any scarce of Microsoft Dynamics professionals, even SAP consultants could become Microsoft Dynamics consultants quite easily and on the way providing great ideas to their colleagues. In Germany I experience a quite incompetent recruiting process, where companies have some positions open for months of even for years because they look for someone which Microsoft Dynamics experience but also with fluent german, when in most of the cases that it is absolutely not needed.

IT Partners

Microsoft Dynamics Ax is on the market since more than a decade and there is plenty of Microsoft Partners in which you can confide, some of then are specialized specific sectors like retail or industry. Companies like my actual company Alfapeople, MODUS Consult, COSMO Consult, Avanade, HSO, Impuls and SPH are good examples of them, and in Spain Prodware, AxAzure, Iniker IFR and Quonext are examples of high productive spanish Microsoft Partners. Worldwide I can mention companies like Sunrise Technologies, HSO and K3 but also the network of Alfapeople 🙂

SAP Partners there is also a lot out there specialy here in Germany, some of them lying on offices that look like palaces that shows how much money was won with SAP in the last decades. Now it is time for them to prove if they are worth their money and for all the current SAP users to take a look at Microsoft Dynamics Ax. They would be surprised to see how much money they can save and but most important how they will be able to become more agile reacting more quick to the needs of their customers in a more interconnected, cloud oriented world.

Pedro Rodriguez Parra
Dynamics Ax Developer at AlfaPeople GmbH

Three Ways You Can Recover From an ERP/CRM Failure

CRM, Home Page, Projects

Recovering from a failing  project is an incredibly difficult process. It can require a change in project scope, a hard look at requirements, an introduction of new methodologies and clear project controls. In some extreme situations, the project team and consultants may need to be replaced.

After a sobering, no holds barred assessment; the following actions must be taken.

  1. Re-examine the ERP Software. Determining if the ERP/CRM software was originally a good fit for the organization is the first step to recovery. The recovery team must determine if the project team evaluated the ERP/CRM options appropriately or chose specific software based on invalid assumptions. While the software is often the immediate culprit, often times it is merely a symptom of the real failure issues: failure to provide adequate change management and/or clinging to outdated processes.
  2. Reorganise the ERP Project with the Experts. A failing ERP/CRM implementation shares many characteristics of bankruptcy. Reorganisation, refocus and accountability are necessary actions to begin the road to recovery. An independent set of eyes can avoid the blamestorming game, move the project into results-oriented brainstorming and ultimately get back on track.
  3. Identify, Educate and Provide the Resources to Move Forward. While it is tempting to throw the failure out the back window, walking away does not solve issues that required an ERP/CRM implementation in the first place. In fact, simply trying to erase the ERP/CRM system will do nothing but derail future effectiveness, agility and return on investment (ROI). The right resources are likely inside the organization and can be refocused on the revived ERP/CRM implementation with the right mix of leadership, change management and backing.

One thing seems abundantly clear: there are still a great deal of ERP/CRM and other software projects running off the rails. Blaming and rebooting ERP/CRM vendors is only one fix in a broader ecosystem that includes the government customers and the system integrators. Solving this problem requires close coordination and an independent catalyst to keep them on track, on time and on budget.

Written by Rich Farrell, Senior Manager of Client Services at Panorama Consulting Solutions.

CEOs want CIOs to stop using jargon and focus on business needs

Home Page, Projects, Strategy

Public sector CIOs shouldn’t underestimate the IT literacy of CEOs and need to focus on collaborative working, the organisation’s use of data and solving business issues.

At a recent workshop, around 20 local government CEOs called on CIOs to “reshape their teams” to suit the future needs of the organisation, said a report by not-for-profit organisation Eduserv.

“Sometimes dealing with IT feels like heavy lifting all the time, trying to get behind and beyond the ‘tech speak’,” the report said, quoting one chief executive officer.

“Their frustration is with claims coming from IT – either suppliers or in-house teams – that they can ‘enable digital services’ or ‘deliver transformation’, without specific examples of real business issues solved by technology, with measurable outcomes relevant to the challenges they face,” it added.

Jos Creese, prinicipal analyst at Eduserv, chaired the workshop and said CEOs believe technology can help transform councils and enable efficiency.

“It is logical that CIOs should play a role in helping organisations realise these gains. The opportunity for heads of IT and CIOs is to step up to these strategic challenges, seizing the chance to assist CEOs in driving and reshaping their organisations into the future,” Creese said.

IT jargon misses business targets

However, public sector chief executives want CIOs to “stop talking about IT and focus on solving business issues”.

“CEOs relayed a feeling that at least some IT professionals are still not in tune with real business needs and pressures, and are still too focused on clever technologies, rather than what it can do to transform service delivery,” the report said. It added that poor alignment of IT activity and business priorities remains an issue.

One of the main frustrations outlined in the report is the lack of data on how people access and use public services.

“While acknowledging the limitations of legacy systems, CEOs could not understand why IT seems to find it so hard to unlock data for wider re-use and provide better customer insight,” the report said.

Local authorities face constraints around budget and culture to change, and CEOs recognise that leading IT “is a tough role at a very tough time”.

In dealing with internal barriers, one CEO said IT teams must think about how they can work across different parts of the organisation to “reduce resistance to change”.

The report highlighted the need for collaboration and use of national frameworks across councils, urging CIOs to implement IT systems without proprietary lock-in, to link up with others.

Other requirements from CEOs include: Solving legacy IT problems; stop buying IT that won’t benefit the councils’ needs; and “doing away with Victorian ways of working” in IT teams.

Why it’s time to STOP “Adding Value”

CRM, Projects, Strategy

It’s probably the most commonly proposed response to price pressures and commoditisation: if we’re not prepared to cut our prices, we had better add more value for the customer. It’s a reasonable objective, but the sad truth is that most so-called “value-added” strategies simply add cost and complexity without making the offering any more desirable to the customer. In fact, they often have the opposite effect. Continue reading “Why it’s time to STOP “Adding Value””

ExpressRoute for Office 365

CRM, Home Page, O365, Projects, Strategy

Announcing general availability of ExpressRoute for Office 365

Today we’re pleased to announce that Azure ExpressRoute for Office 365 is now generally available from these network operators:

  • British Telecom
  • Equinix
  • Tata Communications
  • TeleCity Group
  • Verizon

You can read about how Microsoft is using ExpressRoute for Office 365 in the Microsoft IT whitepaper, “Optimizing network performance for Microsoft Office 365.”

Connecting your network to Office 365 using Azure ExpressRoute

Depending on your network configuration, here’s how you can work with network operators offering ExpressRoute for Office 365 to establish a connection between your network and Office 365:

  • If your organization already uses Azure ExpressRoute, your network operator can simply turn on the connectivity for you. Since use of Office 365 generates additional network traffic, you should discuss the requirements for additional bandwidth with your network operator.
  • Organizations using IP VPN technology for a WAN provided by a network operator can ask the network operator to add Office 365 as a node on your WAN. Once Office 365 connectivity is added, Office 365 services appear as if they are on your WAN—like an offsite datacenter.
  • ExpressRoute can also support large or point-to-point network connections. If you have a large broad network, then you may already have a network connection in a co-location facility where Azure ExpressRoute is available. You should work with your network provider to identify the best way to connect to Azure ExpressRoute.

 

Frequently asked questions

Q. Where in the world is ExpressRoute for Office 365 available?

A. Your users can connect from anywhere in the world that your network operator provides access. Each network operator connects to the Microsoft network at specific locations. They can provide networking from the user location to the Microsoft network connection. You should discuss the options with your network operator. The locations where they will connect to Microsoft’s network are listed here.

Q. How do organizations purchase ExpressRoute for Office 365?

A. Organizations interested in purchasing ExpressRoute for Office 365 should have an Azure subscription and should discuss details of the connectivity with an Azure ExpressRoute partner.

Q. Are there any Office 365 services that Azure ExpressRoute cannot provide a connection to?

A. Today connectivity is available for Exchange Online, SharePoint Online, OneDrive for Business, Skype for Business Online, Azure Active Directory, Office 365 Video, Power BI, Delve and Project Online. Services that ExpressRoute does not provide connectivity to include download of Office 365 ProPlus installation files, Yammer, Domain Name Service and Content Delivery Network servers.

Q. Is QoS supported on Azure ExpressRoute?

A. Yes. QoS is supported for Skype for Business Online over Azure ExpressRoute for Office 365.

Q. Does Microsoft provide tools to test for network performance issues?

A. Yes. We have the Office Client Performance Analyzer (OCPA), which was recently updated to add a number of new performance test metrics. Azure ExpressRoute for Office 365 may be a solution to network performance problems experienced by users. OCPA can be downloaded from the Office 365 admin console here.

For customers with Premier support contracts, Microsoft has a service offering for Office 365 Network Performance Assessment. Please contact your Technical Account Manager for details.

, on

5 Business Benefits you can measure from new CRM/ERP systems

CRM, Home Page, Projects, Strategy

ERP-Capabilities

Every organization has a different reason to implement a new ERP system. But the most successful ERP implementations are those that coincide with the desire to improve their tangible business benefits.

Unfortunately, most organizations have trouble realizing the potential of their new ERP systems and most organizations fail to realize at least half of the business benefits that they expect.

The good news? In general, most successful implementations deliver some common benefits. Below are five tangible business benefits that you can achieve with the right focus and expertise:

Increased revenues. Top-line revenue growth is the name of the game in today’s relatively weak global economy. Unfortunately, too many organizations leverage ERP software to minimize costs and neglect to capitalize on the opportunities to increase revenue growth. Modules such as CRM and advanced demand planning can help ensure that your sales team can sell more and that your operations are able to deliver on that customer demand. The key is to look at the inefficiencies in both your customer and revenue-related business processes to identify opportunities to improve your top-line revenue growth, which can be accomplished via your business process reengineering efforts.

 

Increased inventory cycle times. Most organizations hold too much inventory or build too much capacity to compensate for not being able to accurately predict demand for particular products or services. With modern ERP systems, organizations should be able to better predict customer demand and manage inventory accordingly – minimizing the need to unnecessarily stockpile excess inventory and capacity. We’ve found that this business benefit alone can be enough to pay for a new ERP system multiple times over within a few years of making the investment.

 

More efficient business processes. Most organizations have a hodgepodge of inefficient business processes, manual processes and legacy systems that are a bad combination of both grossly inefficient and expensive. New ERP software can often fix this problem, but only if those processes are carefully defined and reengineered. Don’t fall into the trap of ignoring your current business processes or assuming that your new ERP system will define your new business processes for you – both steps are required to ensure that you close the gap between your more inefficient “as-is” processes and your desired “to-be” processes. Defining your new business processes – along with performance metrics and transition plans to get there – will ensure that you leverage this commonly underutilized business benefit of ERP systems

 

Integrated business processes. Similarly, integrated business processes can deliver a great deal of ROI to organizations implementing new ERP systems. Better integration between customer service, production, accounting, sales and other key functions in your organization will help drive top and bottom-line financial growth. The key here – much like a few of the other business benefits identified above – is contingent on carefully mapping your business processes and defining a plan to transition to those new business processes. By carefully mapping your business processes and developing a transition plan, it is imperative to incorporate an effective business process reengineering and organizational change management plan to ensure success.

 

Higher employee morale. Although it may be a bit tougher to measure than some of the other business benefits mentioned above, employee morale typically increases over time as a result of a new ERP system. Transactions are easier to execute, there are less manual process workarounds and new systems are typically more intuitive and easier to learn. It may be more painful at first as employees are learning the new system, but those pains are typically short-lived and outweighed by the long-term advantages. A comprehensive and effective organizational change management plan can help ensure that you maximize employee morale as a result of your new ERP system.

 

The key to realizing any of these benefits is to define them up front and to establish key performance measures and targets. Once this is complete, then those benefits and metrics should be assigned to key business process owners to hold your team accountable for realizing those benefits. Only then can your organization do what most fail to do, which is to realize the full benefits potential of your new ERP system.

September 23, 2015   Eric Kimberling

 

How agile project management can save time and money

Home Page, Me, Projects, Strategy

A lack of focus on business objectives from the start of a project can make them drag on, costing both time and money. Applying agile project management is one way to mitigate the risk, argues Chris Maund.

Current approaches to project management are often thought to slow down business change. As a result, a high percentage of projects are seen as failures. However, it is often not the project management methodology that is slowing down the delivery; it is a lack of focus on business objectives or outcomes from the start of the project.

A while ago, I was brought into a project which had become so caught up in the definition of requirements that a year after starting it had still not benefited the business; in fact, the requirements document was still not signed off.

The project was in the financial services sector with an objective to meet a fairly simple piece of industry regulation, but every time the requirements were analysed, implications for lots of other processes and systems were identified and the scope was duly expanded. The project just continued and continued with more time and money being spent, without checking back to the original business objective. The outcome would have been an overly complex and overly engineered solution.

Employing agile project management

When we took over, we went back to first principles and went through the requirements, refusing to accept anything that did not add value to the original objective. In two months, we had the requirements document signed off and delivered the whole project in nine months, with multiple intermediate deliverables, each adding value to the business.

We call this agile project management, a concept that has been around for 20 years. It is nothing new, but it is most commonly associated with software development, so a lot of people think it is just for IT. In fact, the principles can be applied to a broad range of projects.

PRINCE2 and agile

The strong project management methodology, PRINCE2, is well known and widely accepted. The problem is, it is quite a complex methodology. Many people who use it do not understand how best to apply the toolkit. If you acted on all documents identified under PRINCE2, it could take years to deliver a project. You should only use the tools that are appropriate for the project you are working on – not every tool in the box.

In agile project management, you still use the PRINCE2 documentation set, report on risk and control spending, but you do it in a way that is fit for the purpose of the project.

It’s not just a sensible approach for companies wanting to save time and money on their projects; agile project management is becoming an imperative. All kinds of industries are facing disruptive forces generating from new market players, the internet and related technologies. Only an agile approach can deliver projects fleet-footed enough to offer rapid return on investment in the face of these complex and ever-changing demands.

And think, if you are not looking to disrupt your business model, your competition almost certainly will be.

This is an edited version of an article that originally featured in Raconteur’s Project Management 2015 supplement.