We believe that the current view of best practice in IT Project Management is flawed. As a consequence, failing to rectify the situation can add millions to an organisations cost base. There is a myriad of things that can go wrong when replacing a core system. However, if the training, tools, practices and disciplines that are deemed best practice for project managers [PM’s] are fundamentally flawed and failing organisations, then the situation is greatly and dangerously exacerbated.

The key to successful IT Project Implementation, is to develop a dynamic system of processes and practices that can quickly and effectively respond to constantly emerging risks. Some experienced PM’s break the ‘rule book’ and intuitively intervene in the delivery of a project in a way that prevents disaster. Such PM’s are the treasured few. For the most part the moves they make and the actions they take are instinctive; ask them to give their thinking for why and when they intervened and they will struggle to explain themselves.

In this article we describe and codify some of these ‘intuitive’ interventions and explain the rationale for their use. Our aim is to show that there is an alternative way to manage large enterprise wide IT implementations and in the process, save organisation millions of dollars of cost and substantially reduce project risk.

Our findings are based on interviews with Ennovate’s Directors in which we capture their experience of project managing dozens of separate IT implementations across Europe and Ennovate’s experience of providing a project recovery and client-side advisory service for enterprise-wide system integration.

Ennovate’s approach to IT Project Management is to:

1. Develop a single page project view of the Project that is simple and easy for all to understand and to avoid the tendency to manage the implementation at task level.
2. Create short and real milestones every 6-8 weeks. We believe that this is essential to achieving high levels of productivity.
3. Set-up a project ownership structure with single owners and develop a direct style of meeting practice that focuses on owners’ reporting exceptions. Ennovate’s approach to IT Project Implementation is to use these meetings to design real-time corrective interventions.
4. Design and implement early prototyping by getting business stakeholders to own usability designs and gain their early participation in prototyping. Ennovate’s aim here is to move the technical team out of a mindset of perfect build and test and into one of learning together.
5. Encourage project conflict. If managed well and all stakeholders are made to focus on the project goals, encouraging project conflict is a powerful method of keeping the project real and promoting the necessary pragmatic trade-offs.
6. Avoid the natural desire to over-specify and resist complexity. Both users and technical staff need to be managed away from this inherent tendency.
7. Facilitate changing scope by ensuring project goals remain alive in the project yet promote pragmatic negotiation of scope as part of the project delivery.

In summary, we advocate promoting a candid style of project management. This is one that seeks commitments and clarity at every opportunity and does not tolerate behaviour that deflects from the projects overall goals. A sharp focus on the projects final outcome is maintained and individuals are coached and mentored to take personal accountability and pride in their contribution.

1. Develop a Single Page Project View
   Large IT projects have a typical pattern starting with business requirements and then going through technical design, build and configure, various iterations of testing, migration and ending with user acceptance. Each phase involves tasks and assigning task ownership. Typically, reporting focuses on progress at task level with some level of interpretation during the aggregation process required for summary reporting. This approach, deemed best practice by project management authorities, does not take care of the problems with interpretation and aggregation, nor does it lend itself to keeping a simple coherent view of the project that all project members can understand and relate to.Our approach, based upon Commitment-based Management is different. We focus on building a top down, single page view of the project. First we develop a unifying project goal and maintain this throughout the project. We work with the project team to design their promises and help them relate to and understand how they contribute towards the project goal. This results in a simplified programme structure with clear accountability and commitment to the projects success. Reporting focuses on how the team are doing against managing their promises and the actions required to keep, renegotiate or support each other in delivering upon such promises. In doing so, the project is focused on the future, maintains simplicity and unity to the overall project goal. Another outcome is that the project reporting requirements are simplified and the work of the project office moves from simply reporting and interpreting progress to value adding activities such as supporting the team in managing the delivery of their commitments.
2. Real Milestones every 6-8 Weeks 
   Projects with a six-month-plus duration and a large and diverse range of interested parties, have a difficult time maintaining the momentum and energy of all involved. This can mean milestones are fudged resulting in the erosion of trust between the project team and their stakeholders.Our approach builds upon a project team that understands the overall project goal and how its promises are part of that goal. Ennovate then design and plan 6-8 week milestone deliverables. In addition, we introduce an operational meeting practice that focuses on the commitments pending and actions required to safe-guard them or re-negotiate them. In doing this, the project team focus on outcomes required from each milestone and maintain high energy levels and conviction.
3. Promote an honest and straight talking meeting practice
   In our experience all projects have a tendency to slide into working in silos. When teams operate in silos they move away from having a clear goal of the greater project good and look to focus on their own deliverables. The sum of their deliverables inevitably falls short of the required overall project goal. The team fragments, with each deliverable competing for limited resources. Project managers and leaders can fall into the trap of refereeing or making priority calls based on the strongest personality’s representation. Furthermore, this tendency, when it extends to the business community, creates additional work. Users begin to focus predominately on their own needs and end up specifying nice-to-have requirements in the name of future proofing. This leads to unnecessary workload and unnecessary development effort which results in spiralling implementation risk.In Ennovate’s experience, the typical response to this situation is a generic cry for charismatic leadership. This is helpful, but does not ensure success in preventing silos from emerging.Our approach is to get the project team to maintain focus on the overall project goal. Our operational meeting practice provides a process of renegotiating commitments / promises and is a practical way of ensuring that the team is in regular dialogue on the projects goals, the interdependency of their promise on others and vice versa.
4. Encourage Business Stakeholders prototyping as early as possible
   IT Projects based upon the traditional project management frameworks, are designed and implemented in a way, where the requirements are handed-off to project technical team members and little is heard from the development team until they are ready for the users to re-engage at acceptance phase. This approach generates a number of risks, one of which is that the business moves on and the original requirements are no longer relevant. Business users compensate for this situation by putting forward extensive and very often, unnecessary requirements, while technology delivery teams build completly over-engineered solutions. The consequence is additional time and risk introduced into the project with the likelihood that the business community begins to lose interest in the project. The challenge here is how do you maintain business community commitment and prevent this from happening?Ennovate’s approach is to bring the business into the project. We introduce a dynamic change management practice through the design and build phase and maintain a practical perspective on requirements and changing business needs. In addition, we look to push through an end-to-end transaction early in the project cycle. This sharpens the overall project deliverables and gets the business community meaningfully engaged earlier in the process. This also gets the users and core project team focused on real issues that can be resolved pragmatically.
5. Promote Project Conflict
   Projects tend to be a microcosm of the organisational structure and represent the organisational culture in a magnified way. When things go wrong, which is inevitable, the success in managing such conflict will be critical for getting the project delivered against its goals and time commitments.Some see conflict as a bad thing, Ennovate do not. Healthy teams bring disagreements and conflict out into the open and deal with it. Our style of working is to encourage openness and candour to get conflict out early and deal with it. Our project teams are trained to deal with conflict and listen to the breakdowns in order to design constructive exchanges that help re-align the team to their stated goals. In fact, regularly encouraging disputes to occur and resolving them, quickly adds to the team morale and their sense of creating a real difference.
6. Resist Complexity 
   Managing scope, budget and timelines is a mandatory competency for all project leaders and managers. However, the training project managers receive and the commonly held best practice for project risk management, is to eliminate and minimise scope creep. In our experience, this has the opposite effect on managing scope, budget and timelines. For instance, when a project manager receives a new requirement or change request, the project managers natural instincts are to encourage the functional designer to over specify, conservatively estimate effort and scope and negotiate to eliminate as many changes as possible. The result of this situation is extra redundancy in scope, an unwillingness to accept change and an emerging distrust between the users and the project team.We see budget, timelines and scope as a series of commitments that need to be negotiated and managed throughout the project. Our focus on managing these commitments are forward looking. By getting the users to work with the project team and make commitments by giving them a forum to discuss in the various meeting practices, we keep the project alive to the concerns of the customers. This approach minimises wasteful, non-value add activities that have a tendency to creep into projects based on the emergence of distrust between the various stakeholder communities. The result is a project implementation that delivers the business benefits at the minimum effort and cost.
7. Promote Pragmatic Negotiations and Scope Changes
   The success in all projects boils down to the team’s effectiveness in managing change. The commonly held view in project management is to get buy-in from all parties and negotiate change through a series of change control practices that escalate upwards to a steering group based on the impact on project scope, budget and timeline. As mentioned above, project managers are risk adverse by nature and see change as a potential threat to the project’s success. In fact, some even get territorial and fanatical about maintaining the status quo, i.e. make a strong case for minimising change.Ennovates view is different. Our team is trained to see that changes are necessary to a projects success and introduce ways of managing change through negotiation with all stakeholders, building trust in the process. When this happens, change becomes part of the mind-set of the project team. Only changes that are required by the business will be proposed, the opportunity to remove requirements that are no longer necessary will exist and costs associated with managing change will be minimised. In fact, pragmatic trade-offs that swap one requirement for another is key to successful implementations and results in reduced effort and cost. Such change management practices will help ensure that the project delivers upon its commitments in an effective and efficient manner.

In summary, do not be afraid to ask any system integration partner to tell you about their success rate and do be prepared to probe behind their answers. The truth may surprise you, provided you get to it! What the project management industry does not tell you is that replacing a core system never goes to plan, will cost more than your most generous estimates and demolish any contingency you might have, causing huge business disruption in the process. Ennovate’s approach and experience tells us that we can dramatically reduce this risk.

The question I pose to you is whether you agree with the forecast or have your own ideas as to what will materialize CIO-wise in the coming year.  As always, your comments are welcome.

Rosslyn Analytics Announces Its Annual Five Predictions for Chief Information Officers in 2012

New York and London – November 22, 2011:  Rosslyn Analytics, the leader in one-click data discovery and business intelligence software, has revealed its technology predictions for IT departments in 2012. These predictions have been developed based on conversations with customers, partners and industry experts.

“The hot topic for 2012 will be helping businesses get a grip of the intellectual property that sits within petabytes of enterprise data,” said Hugh Cox, Chief Innovation Officer, Rosslyn Analytics.  “Unlike the past few years, social media technologies will be given a back seat as organizations return to the age old problem of business intelligence. CIOs will be asked to find alternaive solutions to legacy reporting solutions which will provide decision-makers with a centralised hub of on-demand information.”

2012 Predictions:

1.      The end of traditional ETL.  The market will witness the introduction of innovative cloud-based data services that eliminate the traditionally manually-laden process of extracting, transforming and loading (ETL) data directly into a visualisation platform for and by business users.  The obstacle to date has been a lack of interest from vendors to develop the next generation of ETL tools that would eat into existing consultancy-led revenue streams.

2.      Web 3.0 enterprise data platforms emerge.  Customer demands for continued simplicity of managing data, infrastructure and apps will spur the development of ubiquitous data platforms that marry platform as a service, infrastructure as a service and software as a service.  Business and IT users will have a single online portal to facilitate on-demand access to self-service tools to extract, transform and analyze from a personalized hub enterprise data 24/7 without the support of service providers.

3.      Enterprise app stores become hot property. The consumerization of business-to-business technology will accelerate the launch of a plethora of new enterprise app stores.  These stores will provide end-users with iPhone app-like self-service BI tools including instant data quality diagnostics, data profiling and data cleansing services.

4.      IT implementations become strategic.  Chief information officers will increasingly embrace cloud computing in order to become more strategic and relevant in an era when the management of data, not infrastructure, will be the competitor differentiator for businesses.  To be seen as more than a tactical help desk, IT departments will move up the value chain and become smaller yet more strategic in their skillset and approach.

5.      Organizations add third-powers to cubes.    In an era of big data, the traditional data cube has outlived its efficacy.  Traditional data cubes lack the capability to permit business users to manipulate (and interact with) large quantities of data on the fly, thus severely limiting the completeness and quality of enterprise data for analysis.  2012 will witness organizations moving beyond defined data cubes and embracing radical dynamic data cubes for real-time self-service data enrichment and big data analytics.

Monday’s Prognosticative Post: Rosslyn Analytics predictions for the Higher Education Sector in 2012 

30

A. Keep a check  on your storage loads

The storage workloads for virtual desktops and
virtual servers can be very different. If you place a virtual machine on a host without
considering its disk I/O usage, you might create instant resource bottlenecks.

To avoid this, you should have a basic understanding of how much disk I/O a virtual
machine will generate based on the applications and workloads it will host. Also, high disk
I/O virtual machines should be equal among both physical hosts and data resources. Too
many VMs with high disk I/O on a single host might overwork the host’s storage controller.
At the same time, too many high disk I/O VMs accessing one storage system or LUN can
also create performance bottlenecks. So even if you know a lot about your virtual machine’s
disk I/O workloads, you should still use performance monitoring tools to get a more in-
depth look at your environment such as average and peak usage statistics

Also, keep in mind that virtual machines may not always be on the same host. VMs are
mobile and might be moved to another physical host. It’s risky having a group of Exchange
servers end up on the same host; it could bring the whole disk subsystem down. Many
storage managers use VMware Distributed Resource Scheduler (VMware DRS) to balance
workload among hosts, but be careful when using it; it only balances the workload based on
CPU and memory usage, not virtual machine I/O disk usage. In cases where you do use
VMware DRS, make sure you use DRS rules that keep specific virtual machines on different
hosts.

Tip 2. Avoid intense disk I/O. Certain scenarios with your VMs may create periods of
very intense disk I/O, which can create such high resource contention that all of your virtual
machines will slow to a crawl. For virtual desktops this can be caused by time-specific
events, like all of your users turning on their desktops at approximately the same time each
morning — often referred to as a boot storm. While that kind of situation may be
unavoidable, there are ways to deal with it such as by adding large cache controllers like
NetApp’s Performance Acceleration Module (PAM) to your storage device, or by using
automated storage tiering technologies that can leverage faster storage devices like solid-
state drives (SSDs) during periods of high disk I/O.

Other scenarios — like virtual machine backup windows and scheduled VM activities such as
antivirus scans or patching — are controllable. Having concurrent backups running on
multiple virtual machines on a host or data store can cause high disk I/O that will impact
the performance of other VMs running on the host or data store. Try to schedule your
backups evenly so you don’t have too many backups occurring simultaneously on the same
host or storage resource. You should also consider backup applications that avoid using host
resources by accessing the VM data stores directly to back up VM disks. And some specific
virtualization disk-to-disk backup products can shorten backup windows and allow tape
backups of the disk repositories to occur afterwards without impacting hosts and virtual
machines. For scheduled operations like patching and antivirus scanning, enable
randomization or create staggered schedules to spread the operations over a period of time
so they don’t run simultaneously. You should also be careful when running disk
defragmentation operations; defragmentation generates high disk I/O and can cause thin
disks to rapidly increase in size.

Tip 3. Use space efficiently. It’s easy to use up disk space with virtual machines, but
there are ways to control and limit the amount of space they take up on your storage
devices. For virtual desktops or lab-type server environments, using linked clones can save
a great deal of disk space. Linked clones are similar to VM snapshots where a virtual
machine’s virtual disk file is made read-only and a smaller delta disk is created for any disk
writes that may occur. Linked clones work by creating a master virtual disk image that’s
read by many VMs but all writes occur on each virtual machine’s own delta disk. For
example, if you create 100 virtual machines with 40 GB virtual disks, they would consume 4
TB of disk space without linked clones. If you used linked clones, however, you would have
a single 40 GB virtual disk for all VMs to read from and smaller 1 GB to 2 GB virtual disks

Thin provisioning can also help manage storage space in virtual server environments. It can
be implemented at the virtualization layer or the storage layer. Almost all VMs are given
more disk space than they usually need; thin provisioning allows you to overprovision
storage by allowing virtual disk files to only take up the space they’re actually using and not
the full disk space they were allocated. The use of thin provisioning can greatly reduce the
amount of disk space your virtual machines consume and will give you more control over
costly storage capacity upgrades.

Tip 4. Avoid unnecessary I/O operations. Why generate excessive disk I/O if you don’t
have to? You should always try to limit the amount of disk I/O that virtual servers and
virtual desktops create. This includes disabling any Windows services that aren’t needed,
uninstalling unnecessary applications, disabling file indexing, and limiting the amount of
logging that both the operating system and applications generate. There are many other
smaller things that can be tweaked and they can add up to greatly reduced disk I/O across
your virtual machines. You can use end-point management tools or Active Directory group
policy to help manage and control the configurations. You’ll not only reduce virtual machine
disk I/O, you’ll reduce consumption of other host resources. Reducing the amount of
unnecessary disk I/O that VMs generate is always a smart move as it allows your storage
subsystem to operate at maximum efficiency.

Tip 5. Use the right storage for your workloads. Most hosts have local storage available
in addition to being connected to shared storage for virtual machines. The types of storage
available to your hosts will often have different performance characteristics, such as an 8
Gb Fibre Channel (FC) SAN and a 1 Gb iSCSI or NFS storage device. Besides different
storage protocols, you may have hard drives with different speeds (e.g., 10K rpm, 15K rpm)
and interfaces (e.g., SAS, SATA, solid state). With so many different storage options to
choose from, it makes sense to fit the VM to the right type of storage. Place less-critical
virtual machines on the slower storage tiers and your more critical VMs with higher I/O
requirements on the faster tiers. You can also use an automated storage tiering system like
Compellent Technologies Inc.’s Fluid Data architecture or EMC Corp.’s Fast technology that
moves data between storage tiers based on demand.

You can go a step further by splitting a VM into multiple disk partitions whose virtual disk
files reside on multiple storage tiers according to their performance needs. One common
way to do this is to create separate disk partitions for the operating system, Windows
pagefile, applications and data. The faster storage tiers can be used for the data’s higher
I/O requirements, while slower tiers can be used for everything else. Even if you don’t do
that, you can still specify slower or local storage for the large virtual machine virtual swap
file created for each VM and used when a host exhausts its physical memory. This also helps
ensure that your virtual machine uses less disk space on the more expensive storage tiers.

Overall, simply understanding your storage environment is a crucial step in better
management of your virtual server environment. And following these five tips will make
managing virtual servers easier for the future.

On May 16th, 2010 By Larry Velarde, CBAP®

 We are familiar with the terms strategic and tactical, as they are used in business planning: Managers engage in strategic thinking, planning, or behavior when their purpose is rooted in an understanding of the current business environment and of what is required for future growth.

Tactical, on the other hand, refers to how business agents plan, think, and behave in order to achieve a strategic objective. Tactical takes into consideration constraints and resources, as well as risks and challenges, in order to deliver results in line with strategic goals. It refers to “how” a business achieves a goal, whereas strategic focuses on “what” and “why” a company chooses to do something.

Along similar lines, when it comes to systems and software, Business Analysts also work in a tactical versus a strategic fashion. A Business Analyst is being tactical when he/she is devoted to the effective management of requirements within a project. Being tactical is to focus on figuring out how to elicit, analyze, document, and communicate user requirements for a system, in order to roll out a solution that would meet a pressing business need, all in time and within budget.
 
In such contexts maintaining the strategic vision for the project is also required from the Business Analyst; however, since the focus at this point is on implementing a project that has already been identified as of high-value to the company’s future direction and growth, the strategic dimension logically tends to recede into the background.

And here lies a significant source of confusion on the value of strategic business analysis, because it is extremely difficult to realign a project that has not been chartered with a clear strategic goal.

A familiar example of this, from larger organizations, is the frustration that a project manager experiences when he has been very focused on meeting a deadline and delivering a system implementation that solves an immediate user need, only to hear from a corporate sponsor that the work is good, but that now the team needs to take some extra time to turn it into a strategic solution.    

Naturally, and to avoid such situations, the realm of strategic business analysis is that of pre-project activity. A business analyst should be actively involved in assessing the value of a system implementation before the project is chartered. He/She should play a role in predicting project outcomes and how these might impact the company’s direction, and in developing sound fallback plans to mitigate the risk of a miscalculation. Feasibility studies and building the business case for a change project are some of the most valuable strategic deliverables expected from a Business Analyst.

So, how strategic are your business analysts? Or are they functioning mostly on a tactical role?

Remember that both approaches are equally important. Some often remember them by using the mnemonic device, “strategic is doing the right things—tactical is doing things right”.

The information presented on this site should not be construed as legal, tax, accounting or any other professional advice or service. You should consult with a professional advisor familiar with your particular factual situation for advice concerning specific tax or other matters before making any decision. By using this site you are agreeing to the following Terms of Use

 By Larry Velarde

Large companies undertaking IT projects differentiate between management of a project implementation and management of a project’s business requirements. The implementation is led by a PM (a Project Manager) who is usually a technical resource directing workflow in the IT team. His focus is to make sure that, whichever solution the business is implementing, the project takes place as seamless as possible, on time and on budget.

Unfortunately, this set up also makes room for the possibility that a Project Manager could be very efficient at implementing the wrong solution. And that is the reason why large companies have Business Analysts assigned to projects as well. The BA role is to make sure that the PM gets an accurate description of the business requirements, so that in the end business customers are 100% satisfied with the project.

Both roles are essential: PMs optimize the implementation process, whereas BAs help the business define the user needs, the features and functions the solution should include.

Now, in smaller companies it is common to find these two roles played by the same person, usually an IT analyst with programming skills. This is logical: larger companies are able to pool together a number of IT initiatives, and can save money by having professionals specializing on either PM or BA work across a number of projects, whereas smaller companies cannot afford this and they end up relying on employees with a PM profile to do the BA work.

As an executive in a growing company, you need to be aware of this work division to make sure that someone in your organization is playing both roles efficiently through IT implementations.

For example, if the project is taking a life of its own the team in charge should be capable of putting on the BA cap and ask seriously: is there a requirement creep here? Can we actually trace this requirement to a business need?

Remember, it is unlikely that you have one employee who is a PMP/CBAP on board (these are the respective professional certifications for Project Managers and Business Analysts). In fact some would agree that, in a functional sense, separating these roles produces a healthy tension that is good for projects, akin to the architect/engineer distinction.

To conclude, if now you can appreciate clearly the difference between PM duties and BA duties in your IT projects, here is the golden question that applies to smaller companies:

When you decide to outsource or to buy an OTS (off the shelf) software application, who in your organization is leading the BA activities throughout the project?

Bear in mind that it is in a BA capacity that someone in your team participates in all pre-project activities, the feasibility analysis, the scoping of the project, and in a more noticeable role, the eliciting of requirements from users. BAs are closer to the client. They must have the big picture for the solution, and if they fail at communicating requirements to the PM, they can seriously jeopardize the success of the project.

Vendors will always provide talent to play the PM role during the implementation, as they are contractually bound to deliver the “required” customizations, but the question remains: is your team ready to do the BA part? And if not, are you comfortable with the vendor leading the BA activities instead? Defining what your business needs from the solution and not the other way around?

Learn more about www.leverforce.com

The information presented on this site should not be construed as legal, tax, accounting or any other professional advice or service. You should consult with a professional advisor familiar with your particular factual situation for advice concerning specific tax or other matters before making any decision.