Thursday, November 20, 2008

Application of the Cloud

My previous post was on managing projects in the Cloud and though from a business perspective it makes sense to adopt this infrastructure (or rather non-infrastructure or disembodied infrastructure) to contain costs and receive software as a service, one of the main impediments to adopting this wholeheartedly is in my opinion the security concern. Many companies have sensitive data and if an organization is held against measures such as HIPPA, then it is even more imprative to keep you data centers secure.

An article in CIO magazine highlights how Bechtel seems to have found a practical way to adopt clould computing to manage the security concern and in addition, cherry pick the most effective aspects of it from the four current leaders in the cloud, namely Google, Amazon, YouTube and SalesForce.com:


If you could build your IT systems and operation from scratch today, would you recreate what you have? That's the question Geir Ramleth, CIO of construction giant Bechtel, asked himself three years ago.

The question — and the industry benchmarking exercise that followed — prompted Bechtel to transform its IT department and model it after Internet frontrunners Amazon.com, Google, Salesforce.com and YouTube. After all, these companies have exploited the latest in network design and server and storage virtualization to reach new levels of efficiency in their IT operations. Ramleth wanted to mimic these approaches as Bechtel turned itself into a software-as-a-service provider for internal users, subcontractors and business partners.

After researching the Internet's strongest brands, Bechtel scrapped its existing data centers and built three facilities with the latest in server and storage virtualization. Bechtel also designed a Gigabit Ethernet network with hubs at Internet exchange points that it is managing itself instead of using carriers. Now, Bechtel is slashing its portfolio of software applications to simplify operations, as well as the user experience.

Dubbed the Project Services Network, Bechtel's new strategy applies the SaaS computing model internally to provide IT services to 30,000 users, including 20,000 employees and eventually 10,000 subcontractors and other business partners.

We operate "as a service provider to a set of customers that are our own [construction] projects," Ramleth says. "Until we can find business applications and SaaS models for our industry, we will have to do it ourselves, but we would like to operate with the same thinking and operating models as [SaaS providers] do."

This is probably the most practical solution for the current situation and is probably the only viable one for the next 5 to 10 years, until the future state of ubiquitous clould computing can overcome its security, reliability and data ownership issues.

In additon, it was smart for Bechtel to look at the major players out there and adopt the best of what they have a mimic it in their implementation. Google for their server infrastructure, YouTube for the WAN, Amazon for their virtualization, and SalesForce.com for the SaaS application model. But the best take away from this article was the statement by the CIO, that "what we learned is that you have to standardize like crazy and simplify the environment." Simplification and standardization is the key in making this work.

Labels: ,

Tuesday, October 28, 2008

Managing projects in the "Cloud"

The current issue of the Economist has a special report on Corporate IT and the central theme of the articles is the recent rise of cloud computing and its effects on the governance and management of IT initiatives in the corporate world:
Computing is taking on yet another new shape. It is becoming more centralised again as some of the activity moves into data centres. But more importantly, it is turning into what has come to be called a “cloud”, or collections of clouds. Computing power will become more and more disembodied and will be consumed where and when it is needed.

The rise of the cloud is more than just another platform shift that gets geeks excited. It will undoubtedly transform the information technology (IT) industry, but it will also profoundly change the way people work and companies operate. It will allow digital technology to penetrate every nook and cranny of the economy and of society, creating some tricky political problems along the way.

Because of the dot com bubble of the late 90s, I'm very skeptical to even cynical of such hyperbolie, but in this case I think a majority of the hype is justifed. The key term from the quote above is "disembodied", which is a pretty good way of describing the cloud. Terms such as decentralized, fragmented, and dispirate was and is still used to describe the networks which comprise the internet, but a more stronger term such as disembodied would need to be used to describe clould computing as it allows you to grab a software service from a totally abstracted layer that conceals a very complex infrastructure of data centers and virtualized storage technologies.

The image below from Wikipedia provides a pretty simplified pictorial of this architecture:


In addition, it list the key charactersitics of the Cloud:
  • Capital expenditure minimized and thus low barrier to entry as infrastructure is owned by the provider and does not need to be purchased for one-time or infrequent intensive computing tasks. Services are typically being available to or specifically targeting retail consumers and small businesses.
  • Device and location independence[25] which enables users to access systems regardless of location or what device they are using (eg PC, mobile).
  • Multitenancy enabling sharing of resources (and costs) among a large pool of users, allowing for:
    • Centralization of infrastructure in areas with lower costs (eg real estate, electricity)
    • Peak-load capacity increases (users need not engineer for highest possible load levels)
    • Utilization and efficiency improvements for systems that are often only 10-20% utilized.[21]
  • Performance is monitored and consistent but can be affected by insufficient bandwidth or high network load.
  • Reliability by way of multiple redundant sites, which makes it suitable for business continuity and disaster recovery,[26] however IT and business managers are able to do little when an outage hits them.[27] Historical data on cloud outages is tracked in the Cloud Computing Incidents Database.[28]
  • Scalability which meets changing user demands (e.g. Flash Crowds) quickly, without having to engineer for peak loads. Massive scalability and large user bases are common but not an absolute requirement.
  • Security which typically improves due to centralization of data, increased security-focused resources, etc. but which raises concerns about loss of control over certain sensitive data. Accesses are typically logged but accessing the audit logs themselves can be difficult or impossible.
  • Sustainability through improved resource utilisation, more efficient systems and carbon neutrality.[29]
So from a business point of view, you can view cloud computing as a broad array of web-based services aimed at allowing users to obtain a wide range of functional capabilities on a 'pay-as-you-go' basis that previously required tremendous hardware/software investments and professional skills to acquire. Cloud computing is the realization of the earlier ideals of utility computing without the technical complexities or complicated deployment worries. Therefore, in a nutshell, cloud computing seems to promise limitless computing power and storage space via the internet.

I have no doubt that some day this type of ubiquitous computing availability and services will come about. A tremendous amount has changed since that decade or so when the internet became a truly viable commercial technology. It has no doubt experienced bumps along the way, but there are utility services we enjoy today such as electricity, water and gas that we can acquire without having to think much about it and the downtimes are nearly non-existent, but I'm sure at the beginning had reliability and quality issues.

The Economist articles points out the potential problems to watch for such as reliability, security and ownership of data and information. These are very valid and obvious concerns to me, but one that concerns me the most as person who manages multiple projects that almost always have a IT component to them, is that before cloud computing resolves the common issues of reliability, security, etc. and becomes as ubiquitous and easy to use as utility services, there will be that ramp up curve wherein companies that adopt the cloud and tires to resolve all these issues makes a person like me who has to manage these projects get gravely effected by it.

Furthermore, even without cloud computing, there was a problem of too much software being built and/or purchased by companies looking to automate every process for cost savings or competitive advantage. This came at a very big cost in terms of infrastructure and application investments and caused huge project overruns that delivered applications that brought very little or no value to business. Cloud computing will help with the cost for infrastructure and application implementation, but in many ways the ease with which companies would be able to pick, purchase and use software services will cause more delays and little value, and though cost may be saved in the short run, time will be lost and in business, time is money.

Project managers will have no choice but to adopt a more agile approach, but for many companies such as the one I work for, there is still a need to comply with regulatory agencies such as HIPAA and SOX, which require a process and audit trail to be followed. Its hard enough now to balance these competing needs, I see the adoption of cloud computing with the potential to exacerbate this problem even further.

So while cloud computing promises much, there needs to be a healthy skepticism in one's evaluation of it's benefits.

Labels: , , ,

Wednesday, March 19, 2008

Bridging the gaps of Enterprise software

The following article on gantthead.com bemoans the gaps that occur when trying to roll out an Enterprise wide PPM solution, but could be applied to any ERP type roll out, whether SAP, Peoplesoft, etc. Basically, the gap is not properly preparing for and agreeing on the process and capabilities the tool is suppose to deliver:

But once push came to shove and the time came to actually use the software for the purpose that it was intended, what became very clear is that it didn’t support how projects were managed in the organization. Not that it couldn’t support how projects were managed…but how the software was implemented was not effective based upon where the organization was at the time.

The challenge here was that the organization didn’t really have a process of how it managed projects. There were experienced project managers with their own toolsets, approaches, processes and practices. There was some commonality in terms of template standards that were in place. But apart from compliance with the essential practices of the organization, how any one project was managed bore very little similarity to any other project. What was valued was that projects got done, not that a consistent approach was used in managing them. All well and good, and many might say that it’s the results that matter. However, when you are trying to manage multiple projects in a common information store in order to establish an integrated view of projects and resources, consistency counts for a lot...

Consistency may not be valued on a practical level, but when we expect everyone to use the same software and create any degree of value out of doing so, consistency is essential. If we’re not prepared to be consistent, implementing the software is likely a waste of time. And when we do implement the software, starting off with some basic capabilities and enhancing its use slowly is a far likelier pathway to success. As with so many other things in life, it’s not the size of the software that’s important, it’s how you use it.

This is the typical problem in all IT software roll outs, where you purchase a very fancy tool before you even really know what your going to use it for. It's an absurd logical fallacy, but for some reason, many if not all corporations follow this same illogical pattern.

For a simple example, its like a person purchasing an elaborate set of auto mechanic tools worth thousands of dollars, before even knowing what he/she is going to use the tools for: will they use it change the oil in their car periodically, or do they intend to rebuild classic cars for resale? For the former, it would be a complete waste of investment, and even for the latter, you'd probably want to make sure to what degree do you intend to rebuild classic cars? Do you think you will fix up and resell you old 84 Camero, or do you intend to pick something up from the junkyard and rebuild a car from the ground up?

These are the kinds of questions you'd want to ask yourself, yet curiously I don't really see these questions being asked prior to a company's decision to purchase or roll out a large scale enterprise software solution. Sometimes it just seems assumed you need one of these.

And from this article from InfoWorld, more enterprise PPM solutions seem like they are going to be purchased in the future, not less:

Data from Forrester Research shows that project-related investments consume about 18% of overall IT spending, and AMR Research reports more of its clients are inquiring about PPM and how it can help them avoid costs and improve project success rates. For instance, while 15% of some 230 clients asked the research firm about PPM directly, another 14% requested more information on ITIL and other best practice framework, which analysts say directly relates to PPM.

I'm leading and involved with a similar roll out, and though I may seem one sided and critical, the reality is that where we are at now, with increasingly fast pace of technological and business process innovations, an organization does not have the time to take all the considerations to be carefully deliberated on, and with the increasing ubiquity of technology in all our lives both business and personal, its hard not to want to immediately streamline your processes in a fancy toolset. In addition, with the increasing requirements of regulatory compliance, an organization typically needs all these data points captured in electronic form and in a database.

But stepping back and viewing our sometimes irrational decisions, is comical, disheartening and educational all at the same time.

Labels: , ,

Monday, March 3, 2008

5 Portfolio Management Tips

Gantthead.com has a pretty good article about effectively implementing a PPM system titled "Effective Portfolio Management Implementation Tips". The article gives a pretty good rational for following 5 tactical tips with respect to rolling out a PPM solution:

Tactical Tip #1: Manage portfolio operations reviews using the PPM Tool.
By establishing a weekly or monthly process to update the tool, managers will encourage users to incorporate the PPM system into their daily, weekly or monthly routines. If the PPM solution is tracking project actual hours, users can update the project schedule in the tool daily. Implementation managers should emphasize the importance of using the tool to develop the operational reports required to manage the IT portfolio....

Tactical Tip #2: The project manager will only update the status in one system.
This tip may seem obvious given Tactical Tip #1, but organizations have been know to implement a PPM system only to ask the project manager to complete a new form or template with the exact same information. Instead of wasting the project manager’s time with redundant administrative tasks, encourage the PMOs to generate reports using the data the project manager updated in the PPM system. Managers want “one version of the truth” and populating data manually in two or more repositories further obscures accurate information.

Tactical Tip #3: Implement functionality in phases.
MS-Project integration, dashboard reporting, workflow, collaboration, Web-based change, issue and risk management all look incredibly attractive on the vendor’s demonstration system. Implementing all these features in a real-world environment and ensuring the data is kept up to date requires more than a technical implementation. Change management, training, organizational support all need to be in place to support a full PPM system....

Tactical Tip #4: One PPM System, One Project Status Report.
Project status reports tend to change depending on the target audience. Frequently, managers are asked to provide one status at the project or program level and then provide status in a different format for another targeted audience. Regardless, if the organization needs two different status reports, the data needs be maintained and updated in one system. If the project manager is required to enter data in two places, the PPM system hasn’t helped the PM; instead it added to the PM workload....

Tactical Tip #5: Ensure the project teams have enough software licenses to use the solution.
Effective PPM solutions benefit from collaboration. If the user base is limited to just project managers, the solution quickly limits itself. Effective PPM implementations allow all project team members to enter risks, log potential changes requests, update issues and provide updates to the project schedule. If the user licenses are just licensed to the project managers, the PMs become a bottleneck for administrative updates. During contract negotiation, flexible user license arrangements can be built into the contract. If the tool doesn’t allow the entire project team to leverage the tool, it will quickly become a seldom used tool during project execution.

These tips are quite useful to me, as I am currently managing the roll out Planview Enterprise 9 throughout my organization, and these tips are quite useful to review. Particularly tip #3, as I feel it is very important to release incremental "pilots" of the eventual implementation in phased releases in a development environment.

This ensures no disruptions to the production environment, and allows test users to work with the prototype in a sandboxed environment. I highly recommend reviewing the article if you are in a similar situation.

Labels: ,