IT Project Management

I have recently being following an animated thread on LinkedIn “Death of a Metaphor – Technical Debt.” It’s been live for 2 months with over 200 contributions from dozens of different people.  The discussion was launched by questioning whether continued use of this metaphor makes sense.  The discussion thread weaves and bobs around actually answering this question but it’s amazing how passionate the world is on this topic.  My personal opinion is that it’s a perfectly adequate metaphor because it helps create a discussion between IT and the business leaders in terms that both can understand – dollars and cents. 

Sometimes during software development decisions are made to forgo structural quality to meet some other objective – additional functional requirements, time to market, etc.  How many of us have been involved in a development project where it was more important to get the product out the door than it was to get it done right – we take short cuts with the intent to go back and do it right once the immediate fire drill is over.  The problem is that once the product is out the door and meeting the customers expectation - how do we convince the business that there is as much (maybe more) long term value in fixing a product that is seemingly working than in investing in new features that will make the product more appealing to more users.  What business leaders may not understand is the cost of continuing to maintain and grow a structurally questionable - sometimes brittle – application.  Technical debt is the monetization of that cost making it possible for IT to communicate the value to the business of creating and maintaining a structurally sound application.  Check out this blog for a good discussion of technical debt and how to prevent accruing it.  “Technical Debt gets the Message Across”. 

The IEEE published “Top 11 Technologies of the Decade” in the  January 2011 editions of the IEEE Spectrum magazine.  It should come to a surprise to no one that the Smartphone was number 1 on this list.  The answer to the author’s question “Is your phone smarter than a fifth grader” was a resounding YES![1] 

 In 1983 Motorola introduced the first hand hell cellular phone.  It weighed in at two and a half pounds, had memory capacity for 30 phone numbers, took 10 hours to recharge and had a selling price of $4000 ($8045 in 2006).  The phone was the size of a man’s head and would sustain an hour of conversation before a recharge was required.  In June of 2007 Apple announced that it was launching the iPhone which would basically integrate all of the electronic gadgets teenagers carried around in their pockets into a complete package – phone, web browser, iPod and camera.  The iPhone 5 which should be available by Fall 2011 incorporates NFC technology, an upgraded operating system with cloud integration, music streaming, voice interface, 4G connectivity and an embedded social networking tool. NFC technology makes it possible to use the phone effectively as a credit card – making payments by swiping the phone near a device that can read its information. [2][3][4][5]

The proliferation of smartphones and tablets has led (and will continue to lead) to the proliferation of mobile applications.  And it seems as there are no bounds to the kinds of applications that are being developed for smartphones.  A sampling of some popular applications is listed below:

* Chase Mobile – which allows users to check account balances and review transactions
* Angry Birds – very popular gaming software
* Facebook - allows users to report their status from anywhere
* Yelp – allows users to locate places to eat, shop , etc. along with reviews from local patrons of said establishments

The list goes on but clearly if you can dream it – there’s an app for that (or at least there could be an app for that).  As practitioners in the art of estimation, all this mobile application development leads to the inevitable question of what does it cost to develop mobile apps and how is mobile application development different from more traditional forms of development? 
Mobiles apps can be categorized as either native applications – which run entirely on the device or web applications - with small clients resident on the device which interact with applications running on a remote server.  It appears that in general the web applications are less complex than the native ones, and thus less effort is required to build, test and deploy them.
While mobile application development is still in its infancy so a lot of what is going on in the industry now has a bit of the Wild West feel to it.  This stage of any technology is impacted by learning curve issues which may dampen productivity but at the same time there is the newness factor – where smart people are excited about the promise of new technologies and are willing to work extra hard to make things happen.  So while there is some effort/cost data available for mobiles apps, we must temper our enthusiasm.
Another concern when developing mobile applications is which platform(s) it is being developed for.  If an application is being developed for iPhone, Android and Blackberry the effort is significantly increased.  Although there are elements of the design that can certainly transcend platforms, each of these platforms has its own operating system and development environment. There are additional potential compatibility issues in cases such as Android where there are multiple companies manufacturing devices. Additionally, application developers need to determine which versions of OS for each of the platforms the application will work with.  They also need to be aware of and respect the user interface guidelines developed for the device(s) for which they are building apps.
Mobile applications may need to respond to various forms of external data from sensors, a real or virtual keypad, a GPS, microphones, etc.  They also may need to respond to movements of the actual device as well - so the screen adjusts when the user changes the orientation of the device.  There are also many instances where mobile apps will need to interact with other applications on the device.  Often the mobile application will need to share elements of the user interface with other applications. 
Mobile applications need to be developed in such a way as to limit the consumption of resources.  No matter how good your killer app is, if it drains the phone battery in half an hour no one is going to use it.  Along with all other applications that have access to the Internet, they should be built with a focus on security so that the users data is protected from malicious intrusions.
All of the issues listed above are likely to impact the complexity of the development effort of the mobile application – thus they have the potential to be an important part of the cost equation as well.  In many cases mobile applications are smaller than traditional applications so increased complexity may be offset because the projects and corresponding project teams are small.  Still this increased complexity is important to consider.
Another area where mobile apps are dramatically different than traditional apps is in the testing of the application.  Simulators and emulators exist and can be helpful in some circumstances but they are not always easy to use, effective or efficient.  There are also issues, with some platforms around the maturity of the technology that allows applications to be transferred from the development environment to the mobile device – further complicating the testing process.  Finally there is just the sheer magnitude of making sure that the application functions correctly on all the combinations of hardware, operating system and carriers on which it will be expected to perform.  The cost and effort associated with testing may present significant differences when being evaluated for mobile applications.
Smartphones are here to stay and more and more businesses will want (or need) to develop apps for them in order to remain competitive.  With the technology still relatively immature there is limited data that will help us develop cost models but there is feedback from the field on what issues are most likely to impact costs.  Though the technology is still emergent – there is some data available from commercially based mobile app developments – so at least we have a place to start.
Share your experiences with mobile application development by leaving a comment for this post.

[1] Ross, Philip E., “Top 11 Technologies of the Decade”, IEEE Spectrum, January 2011
[2]  http://www.motorola.com
[3] http://www.apple.com
[4] http://en.wikipedia.org/wiki/Mobile_phone
[5]http://www.ibtimes.com/articles/170418/20110628/quick-look-at-iphone-5-features-as-september-release-date-looks-probable-nfc-camera-8mp-lte-4g-displ.htm

Check out this Report on Big Data from McKinsey & Company published in June 2011. 

Back in the day, when personal computers were becoming widely accepted and Microsoft Windows© was the new cool thing, SneakerNet was a common means of sharing data.   Certainly the introduction and subsequent improvements of networking technology and the Internet have made data sharing a whole lot easier and quicker.  But the concept of Big Data creates a whole new level of opportunity and potential for collecting and using data in ways heretofore unthinkable.

So what is Big Data?   According to the report referenced above – “Big Data” refers to datasets whose size is beyond the ability of typical database software tools to capture, store, manage and analyze.  The authors are cautious not to declare a specific size since lightening fast technology advances may quickly make their number wrong thought they do propose currently that datasets in the few terabytes to several petabytes (1000’s of terabytes).  (hmm… I just had to add petabytes to my Word® 2007 dictionary).  The concept of Big Data requires the collection of data from multiple sources (sensors, smartphones, GPS’s, social media postings, data collected by government agencies, etc.) and performing analysis of that data in ways that will make life better and bring more value to businesses, consumers, citizens, etc.
Some examples of Big Data types of applications include;

* Marketing  initiatives like Amazon.com’s “you might also want …” admonition based on information available about your buying patterns and the buying patterns of those purchasing the same item

* Applications like RedLaser which lets a shopper scan a bar code of an in-store item with their smartphone and get immediate price and product comparisons

* Improved supply chain management through access to data across the supply chain helping manufacturers optimize planning and delivery of new products

* Mobile phone apps that allow merchants to track customers from the moment they enter the store to determine traffic patterns and flows through shelves and displays

* Capabilities like OnStar ® where sensors in the automobile send real time data to the service if the airbags deploy or to alert that a system is malfunctioning.

* Capabilities like ShopAlert that sends coupons or offers to smartphones of subscribers when they are in the vicinity of a store, restaurant or bar

The report actually contains a lot more examples across various platforms and sectors.  They have specifically Health Care, Public Sector, Retail, Manufacturing and the ever growing business of using personal location data.  Within each of these categories – opportunities for creating value as well as potential barriers to adoption are presented.

While the technology and the possibilities create lots of excitement – there are also some areas of concern – how much personal data is too much and how close do we want “Big Data” to look like “Big Brother”.   Certainly there are lots of issues that need to be addressed at all different levels before Big Data goes wildly mainstream – but it seems to me that the possibilities for value and capability will, in many cases, be worth it. 

How have you seen Big Data used?  What possibilities can you see for Big Data applications?  Leave a comment to this post to share your Big Data stories.

Check out this article from CIO magazine about managing your project budget.   The author, Jason Westland, suggests four things necessary to maintain control of your project budget.  While these are not earth shattering suggestions, sometimes project managers in the throes of a project can lose sight of their importance.  The strategies are:

* Continually forecast the budget
* Regularly forecast resource usage
* Keep the team informed
* Manage scope meticulously

Or to put it another way – respect and revisit the Project Management Triangle.  (To learn more about the Project Management Triangle go to this link  and look for the “Respect the Triangle: Scope, Time and Cost” paper)   Successful projects require constant vigilance around scope, people, dollars and the calendar.  The Triangle is an excellent tool for project leaders to use as a visual tool to facilitate negotiations with customers when things change in a project (and things will change!).  You can also check out my webinar on this topic.

How do you keep your projects in check?

There is a ton of code out there and we’re constantly adding more.  Gartner reported in 2009 that there were more than 310 billion lines of code in use worldwide. MS Word has grown from 27,000 lines of code in the first version to about 2 million in 2010.  The Windows Operating System grew from 3 million lines of code in 1992 to 20 Million in 1998.  You get the point – there’s lots of code out there doing lots of the same things that we may want our software to do.

One of the challenges software project leaders have in estimation and planning is successfully quantifying the functionality they can reuse and understanding and communicating the effort and cost associated with that reuse.  In projects where significant reuse is anticipated, reuse is really going to shape the project.  Reuse comes in many forms.  A firm grasp of the types of reuse and the potential pitfalls of such reuse facilities a thorough analysis of the impacts that reuse has on the project.  It is ill advised to expect to get a one to one benefit for reuse.  It is even more problematic to plan on reuse as a quick fix to schedule pressure.  

Some of the things you want to consider:

* Reusing legacy code can be a great productivity booster if the code is stable, well written and some of the original developers are on hand.  On the other hand, if you’re working with legacy code that has become spaghetti code which is only supported by a mildly deranged programmer in the corner cube – you might be better off starting from scratch
* The auto translation of existing code to newer technologies can also boost project productivity but one cannot expect the process to be transparent or without hiccups.  It is important to understand the nature of the translation tool, the amount of preparation required to use it and the expected amount of human intervention to make the translation complete
* The use of Commercial Off the Shelf Software (COTS) can significantly impact the schedule for a software project but there needs to be a thorough evaluation of the capabilities of the COTS against the requirements of the project.  There also needs to be acknowledgement with the consumer of the software system that using COTS software limits the amount of customization possible resulting in the risk that the finished product is not exactly what they expected.

Also it is often more complicated to integrate reused (not developed here) solutions since there is a steeper learning curve during the integration phase.  Code reuse can be a great way to achieve increased productivity but it is important not to assess this improvement over optimistically but rather through a careful appraisal of what the reuse activity entails.

Have a reuse story (success of horror) you want to share?  Post it as a comment to this blog.

While teaching an introductory TruePlanning for Software Estimating course this week at an Army location, I was asked to follow up with a clarification on “percent adapted” calculation. 

The official PRICE training materials definitions are:

• Percent of Design Adapted - the percentage of the existing (adapted code) design that must change to enable the adapted code to function and meet the software project requirements;

• Percent of Code Adapted - the percentage of the adapted code that must change to enable the adapted code to function and meet the software project requirements.

The former, Design, was received by the class as straightforward. Again, this adaptation includes architectural design changes, detailed design changes, and any necessary reverse engineering. Entered as a percentage of the Adapted Code size, this metric essentially captures the effort to modify/ enhance the underlying concepts for data and transaction algorithms.

As my class later reviewed a fellow-student’s modeling of a “real-world” example, we found that our jury was hung on the verdict of what’s really meant by adapting the latter, Code. Again, the instruction is to also enter this metric as a percentage of the pre-determined adapted code size.

But the legitimate question was: “Why isn’t it always 100%?” If we labored to already identify new code, deleted code and reused code… then isn’t any remaining modified code all adapted?

The answer, per our resident software Yoda, is consider the code in terms of modules, not just source lines. To answer what percentage of a target must change to meet new functional and project requirements, evaluate what sub-modules/ CSCIs must change and what are reused WITHIN each module. If an entire module is not modified, then it’s count is reflected in the percentage of reuse. But if module(s) have some components that are modified and some that are not, that information is captured in this latter percentage of code adaptation.

If you’ve followed my blogs, you know what’s coming next: another car example! 

Say I have an automobile to rebuild. The body, wheels & tires are fine. Even the suspension requires no modification. (No car guy would ever accept not spending time & money on handling too, but suspend your disbelief for now).

Only the motor needs “adaptation”… but also, only in certain areas. The ignition, fuel injection, water pump, A/C & exhaust all require little to no adaptation. But the cylinder heads, valves, camshafts, rods, pistons & crank all must be worked on. My percentage of motor component “code” that actually needs modification is clearly less than 100%. 

Of course, the changes made above are a function of what requirements we're trying to acheive, e.g., horsepower, torque, RPM, etc.  Likewise, this analogy holds true in typical software modification. What we are given, as previous deliverables, is more than just total lines of code. It’s functioning modules/ systems that may, or may not, require some re-work under the hood. 

Agree?

Additional insight into how TruePlanning defines and utilzes these inputs is detailed in the True Software White Paper.

At the 2011 ISPA Conference, I conducted a ½ day workshop How To Develop Data-Driven Cost Estimating Relationships  in TruePlanning. The attendees at the workshop learned how to import their own data into TruePlanning and develop custom Cost Estimating Relationships. We covered three case studies:

·         In the UCAS case study we demonstrated how we can build CERs at a higher level to provide a test of reasonableness to the CAPE.

·         In the SRDR case study we demonstrated how we develop a CER to estimate SLOC based on historical data and use the results to within the new code parameter of the UCAS Reconnaissance software estimate. 

·         In the Aircraft case study we demonstrated how we can build higher level trend lines across various aircraft system platforms and classes of aircraft to compare as “ball-park” estimates.

In each case, the attendees learned how to work with real data and develop CERs traceable back to the original data points that generated them. This was a “hands-on” workshop and everyone had a chance at generating a number of CERs. Overall, we had a very successful session and provided a new and exciting capability to our TruePlanning framework.

I also wanted to share with you a few takeaways from this workshop.

• By setting up the trend lines equations in the Equation Cost Object, estimators can create libraries of data-driven CERs for future projects
  • All data used to develop the equation can be attached to the CER to identify datapoints and methodology used.
• The power of this approach is that the CERs are integrated into the TruePlanning framework and can be used with other cost objects (H/W, SW, IT, etc)
• Libraries of CERs can be shared among projects.
• CERs are “white box” and auditable both in terms of the trend line equation and underlying data points.
• CERs represent an “estimating database” in addition to TruePlanning Cost Objects.

If you are interested in obtaining a copy of the workshop presentation including the data files and results, please e-mail me at Zachary.Jasnoff@pricesystems.com .

I’m on my way home from the ISPA/SCEA (International Society of Parametric Analysts, Society of Cost Estimating and Analysis) Conference held in Albuquerque this week.  Attendance was very good (2nd best in the conferences history) and as the content seemed especially good this week.  I attended lots of good talks on topics ranging from SEPM (System Engineering, Project Management) cost estimating, Joint Confidence Levels, Software Estimating, Affordability,  Agile software development and estimating for Enterprise Resource Planning Systems.   Of course, just because the topics are good and well presented doesn’t mean I have to agree with everything that gets said.

One particular talk entitled “Function Points, One Size Fits All” got me a little worked up.  It seems as though there is an on-going and completely unnecessary amount of energy devoted by some to convince the software community that we need to settle on a single method of measurement for software.  The author makes some really good, credible points.  Function Points are a much better method of measuring software if your intent is to compare productivity across or within specific industries.  They help eliminate development technologies, programmer inconsistencies and software architecture decisions from an analysis of how productive an organization is at delivering business value to their customers.

Having said this, I firmly believe that sometimes SLOC (Source Lines of Code) are a better tool to help organizations estimate the costs of the software development projects they are planning.  Knowing how your productivity stacks against the industry is great information when you are looking for process improvement or identifying best practices.  But if you want to know how much the next project is going to costor how many months it will  be before you can deliver content, your own history is much more relevant than the industries.  Not that your history can’t be in Function Points – it just doesn’t have to be.  Many of the weaknesses sighted with SLOC – while they certainly can be considered weaknesses) -aren’t really noticeable when working within a certain context.  Within an organization, software development projects are often similar to previous projects, targeted at similar markets and are being developed by similar teams with similar (on average) coding styles. And SLOC Counting processes can be institutionalized within an organization. When this is the case, SLOC counts are just as good, if not better, than Function Point Counts and probably much easier to count since their count can be automated and does not require certified specialists.

The author contends that SLOC is a bad option because it is hard to estimate early on.  I contend the same is true with Function Points - which if the Counting Practices Manual is followed to the letter – one is required to make an assessment of not only all transaction but also all the data element types and record element types.  The author contends that SLOC is a bad option because there is no standard for what a SLOC is.  I contend that the same can be said for Function Points.  Perusal of the International Software Benchmark Standards Groups’ (ISBSG) database shows that there are several different ‘standards’ for counting Function Points – because one standard was not deemed sufficient by many in the community to meet all software measurement needs.

Don’t get me wrong – I do not disagree with many of the assertions the author made, only the notion that one size fits all.  Let’s be real – software measurement is not easy and there are many different ways to approach it depending on the reasons for the measurement and the circumstances around those needs.  Function Points are a good tool to have in your software measurement tool box, so are Source Lines of Code, Use Case Points and user Stories.  It’s true that if all you have is a hammer every problem is a nail.  Fortunately we have many different tools and should feel empowered to choose the right tool depending on the current need.

Going to ISPA SCEA in New Mexico?  If so, join us for a workshop on data driven cost estimating.  Register: http://www.pricesystems.com/services/predictive_modeling_schedule.asp#/?i=3

Description:  Building transparency and traceability into your estimating process leads to more defendable estimates.  This hands-on workshop demonstrates how historical data is transformed into predictive models.   You will learn how your organization’s data can be synthesized into custom models that can be employed in support of third party models within a single analytical framework. 

Participants will learn:  (1)   To develop system level estimating relationships to provide a test of reasonableness and historical cross-check to proposed estimates. (2) To develop sub-system level relationships that estimate Software Lines of Code based on requirements. (3)  To develop historically-based relationships across classes of aircraft systems in support of “ball-park” estimates based on specific program actuals.

Location:  2011 ISPA/SCEA Joint Annual Conference /  Hyatt Regency Albuquerque - Fiesta 1-2 /  June 7^th, 2011 /  9:00 am – 1:00 pm (includes complimentary lunch).  Hope to see you there!  To register go to: http://www.pricesystems.com/services/predictive_modeling_schedule.asp#/?i=3

I was recently asked by a client to provide a synopsis of what TruePlanning offers in response to the Ashton Carter Memorandum – Implementation of Will-Cost and Should-Cost Management. In the memo, the Undersecretary of Defense AT&L listed “Selected Ingredients of Should Cost Management”. It was interesting to note how much capability is provided by TruePlanning to effectively support efficient should cost management. In this month’s blog, I will share with my response to our client with you.

Agile software development practices are predicated on the following tenets as introduced in 2001 in the Agile Manifesto [1]

•  Individuals and interactions over processes and tools
•  Working software over comprehensive documentation
•  Customer collaboration over contract negotiation
•  Responding to change over following a plan

Agile development processes rely on experienced, highly skilled people communicating with clients and each other to deliver software that provides the clients with the most value for the money they spend.  This requires both developers and consumers of software to accept the reality that things will change over the course of the project and that the software that is eventually delivered may not be the same as that was envisioned when the project was first kicked off.

At any given time, the agile software development team is only working on the feature that the customer currently feels is the most valuable.  Estimation is performed by the team (including developers, BAs, QAs and customer representatives) and is only focused on the feature that is currently on deck.  At the end of an iteration, the customer has an opportunity to review the implementation to date and can reprioritize remaining features based on changes in their requirements, market or expectations.  So estimating beyond the current feature doesn’t really make agile sense.

Unfortunately, the fact that estimation doesn’t make sense for the agile team does not mean it doesn’t make sense for the business.  The business needs to see the forest not just the trees.  Customers need an idea when their software will be delivered, businesses need to prep the market for new products and features, businesses need to be able to optimize resource allocations across many projects, etc.   This of course begs the question of how to perform an estimate for software when you really don’t know exactly what software you’re going to build.  As an industry, we’ve been pretty unsuccessful estimating software projects even when we think we have a handle on the end product – how can we be successful with so much uncertainty.

First we accept uncertainty and commit to incorporating uncertainty into our estimates.  Once we’ve made that commitment we are then free to pursue one of many top level estimating techniques to help us get our head around a likely range of values for cost and schedule based on what we currently know about the software project.  Parametric techniques are particularly suitable for this task especially for an organization that has some historical data from previous agile projects.  Parametric estimating models like TruePlanning for Software provide a repeatable framework through which an organization can study their past performances on similar projects (similar number of features, similar market, similar customer, etc) and use what they learn to perform estimates on the project at hand.   The amount and nature of the similarities should guide the amount of uncertainty in the estimate.  Organizational history can be used to map Story Points or User Stories to a size measurement such as source lines of code, function points or user points.  Analysis of performance on past projects can inform decisions about productivity and other project drivers.  This information can be used to drive the parametric algorithms to develop estimates for cost, effort and schedule.

Since we have already acknowledged that we didn’t get the question right, it’s unreasonable to assume that the answer will be ‘the right answer’.  What we do come away with is a range for cost, effort and schedule which will give decision makers realistic data to work with. If we have properly studied our history and thoughtfully assessed uncertainty, we can present these ranges with a quantifiable degree of certainty. 

What process does your organization employ to plan around agile induced uncertainties?

[1] Agile Alliance, “Agile Software Development Manifesto”, Feb 2001, available at www.agilemanifesto.org (retrieved January 2010)

The following is a collection of some of the more common installation issues.  If you have additional questions, concerns, or issues with any upgrade or installation, please call our Technical Support line anytime at:  1-800-43-PRICE.

Default Password Override

TP’s default password may not be strong enough based on your security policy.  Please review your specific requirements for passwords and follow the directions below to change the default:  When you get to the screen, uncheck the “Use Default Password” and enter a valid password based upon your specific security settings.  Then click next and continue the installation process.

Existing TruePlanning Installations

If TruePlanning 2008 SR2 is currently installed, it is recommended that users export their projects, then uninstall TruePlanning, making sure to backup their database when prompted to do so during the uninstall. The uninstall of TruePlanning can be initiated from the Control Panel.  Also, please select the option to uninstall MSDE when prompted during the uninstall.  Once this is complete, install the new version of TruePlanning, making sure to manually import the projects which were exported from the older release once the installation is complete.  Upgrades from TruePlanning 2009 and above do not require TruePlanning  to be uninstalled as the TruePlanning 2010 installation will automatically upgrade the projects in the database; however, it is recommended that users still export their projects manually and before the upgrade to be safe. 

Administrative Rights

The user installing TruePlanning requires administrator rights on the machine.  On Vista it is advisable to launch the installation of TruePlanning by navigating the “Setup.exe” file on the TruePlanning CD and initiating the installation using the “Run as Administrator” option. This option is available from the right click menu in Windows Explorer (My Computer). 

XmlLite

XmlLite is a resource provided by Windows to perform certain XML parsing abilities. It is a prerequisite for installing TruePlanning 2010. If TruePlanning 2010 is installed on a computer that does not have XmlLite, and error will occur when TruePlanning is launched.  The installation will not produce any errors or warnings. This error is Windows XP specific. Vista and Windows 7 contain the XmlLite natively. Normally XmlLite is installed when Internet Explorer 7.0 (or newer) or Windows XP SP3 are installed. Installing either of these resources should resolve the error.  Some customers are not able to install IE 7.0 or Windows XP SP3 and should therefore install XmlLite directly. It is available from Microsoft at: http://support.microsoft.com/kb/915865. It should be noted that TruePlanning 2010 has features that rely on Internet Explorer 7.0 or higher. Some of the Calculators contained in TruePlanning will not function properly without Internet Explorer 7.0 or higher.  Therefore, if possible, upgrading Internet Explorer is the preferred option. 

MSXML6 SP2

There is a known issue installing TruePlanning 2010 on computers that have Windows XP SP3 and MSXML6.0 SP2 installed.  The issue occurs because of an incompatibility between SQL Server 2005 Express and MSXML6.0 SP2. This issue is described by the following Microsoft Knowledge Base article: http://support.microsoft.com/kb/968749. MSXML6.0 SP2 is installed by the Windows XP Service Pack 3. This is not an issue on Vista.  The above MS KB article provides a fix for the issue. It is advisable to execute the fix before attempting to install TruePlanning 2010. It is possible to identify computers that have had MSXML6.0 SP2 installed by examining the “Add/Remove Programs” feature under the Control Panel. If the issue in encountered during the installation of TruePlanning it can be identified by the failure of SQL Server to install. The failure will be identified as pertaining to MSXML6. This can be ascertained after the installation has been exited, by examining the log of the SQL Server installation. The summary of the SQL Server 2005 Express installation can be found at the location defined by the following support page: http://msdn.microsoft.com/en-us/library/ms143702%28SQL.90%29.aspx. If the error has been encountered please contact PRICE System’s Support for help resolving the issue.

In 1961 at the MIT Centennial, John McCarthy opined “if computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility…. the computer utility could become the basis of a new and important industry”  [1].  In 2006, Amazon Web Services was launched providing computing on a utility basis.  Since that time the notion of cloud computing has been emerging and evolving.

Cloud computing is a paradigm that makes the notion of utility computing a reality.  Instead of Information Technology (IT) organizations investing in all of the hardware, software and infrastructure necessary to meet their business needs, cloud computing makes access to hardware, software and infrastructure available through the internet, generally utilizing a pay for use model.  Basically cloud computing allows an organization to adopt a different economic model for meeting IT needs by reducing capital investments and increasing operational investments, a model which is likely to offer cost savings to many organizations.

There is still a great deal of hype around cloud computing, as many vendors have their marketing engines further into the clouds then their technology supports.  Despite this Gartner predicts that by 2012 one in five businesses will not own its own IT assets. [2].  In late 2010 the Office of Management and Budget (OMB) under direction from the White House told federal agencies that starting in 2012 they are expected to consider cloud first “whenever a secure, reliable, cost-effective cloud option exists.” [3]

There are certainly many reasons why an organization would consider moving at least some of their IT functions into the cloud.  In addition to potential cost savings the cloud offers the possibility of increased availability, easier collaboration, lower capital costs, scalability and virtualization.  There are of course concerns as well.  The technology is still relatively immature with no definitive set of standards for interface or compliance with regulations.  Businesses lose hands on control of their IT resources with little recourse if their IT vendor shuts down or goes out of business.  Additionally,  there are security and data privacy concerns.  There is also the fact that not all ventures into the cloud will be cost effective for the business.

This paper introduces the concept of cloud computing and discusses the potential benefits for a business as well as those things which could be barriers to adoption.  It examines the types of applications where cloud computing is an efficient cost effective solution and the types of applications where its use could be problematic or costly.  Several examples of successful cloud implementations are presented and discussed.

For a white paper describing this reearch on cloud computing email info@pricesystems.com with the code word CLOUD in the subject line.  To share your cloud computing experiences comment on this post