Tag Archives: IT projects

Good news: IBM-led shared services company is recognised as “failing”

By Tony Collins

After years of depicting problems at an IBM-led shared services company, Southwest One, as teething, Somerset County Council has conceded that the venture is failing.

The Conservative leader of Somerset County Council Councillor Ken Maddock used the word “failing” nine times in a speech on Wednesday about Southwest One, a company run by IBM on behalf Somerset County Council, Taunton Deane Borough Council and Avon and Somerset Police.

Southwest One’s contract, which was signed in the early hours of a Saturday morning in 2007, was doomed from the start, in part because of the complexity of the arrangements and in part because of pervasive secrecy that antagonised hundreds of Somerset council staff who were already opposed to the joint venture; and they were the very staff who were seconded to Southwest One to make the venture work. [It’s a truism that staff, if they are motivated, will often make their way around difficulties but may be overwhelmed by them if not motivated.]

Last month Campaign4Change set out in detail some of the most disruptive and continuing problems at Southwest One; and we said the difficulties could not be tackled in earnest while Somerset council and its partners were portraying the venture as a success. On 31 January 2012, our post was mentioned on the website of the local Conservative MP Ian Liddell-Grainger.

The good news now is that the council has, this week, for the first time, spoken of Southwest One in unequivocally negative terms. No longer is every council criticism of the company qualified by a positive comment, such that one cancels out the other.

Whether our post last month has made any difference is not important. What’s pleasing is that IBM and Southwest One’s partners are free to make progress, now that Somerset has told it like it is. Much of the credit for the council’s emergence from its long, self-administered anaesthesia lies with Dave Orr who has campaigned for years to highlight the failings of Southwest One, as has Liddell-Grainger.

Maddock’s speech on Southwest One

Maddock’s speech to a full council meeting is reported at length by the Somerset County Gazette and by Liddell-Grainger.

Maddock said

“As an administration we inherited a partnership that promised a huge amount, but it was not delivering. Southwest One’s accounts year on year show losses, staggering losses just published of £31m, and failures to hit modest savings targets.

“We have bent over backwards to try to make this partnership work. But we have to state clearly that our primary duty in looking after the public’s hard earned money is to make sure we get the best possible deals, that we get the best possible value for the public’s money.

“I have to say that Southwest One is failing this test.

“We are currently looking at all our services and all our contracts to see whether we are doing the best we can for our customers,  whether we are providing the best possible services for our customers and at the best possible prices for our customers.

“I have to say that Southwest One is failing this test.

“We need a Council that can cope with future government cuts and rising demand. We will need to be efficient and flexible.

“I have to say that Southwest One is failing this test.

“Sadly, Southwest One is failing. It is failing to deliver promised savings; failing to cope with a changing financial landscape; failing to be flexible enough to adapt in challenging times and provide the best possible value for money.

“To make up for this failure, we will now accelerate our extensive review of everything that the council does: Almost half our most vital services are carried out by private sector or not for profit organisations – we will look to increase this where appropriate.

“We will encourage social enterprises, partnerships, communities and voluntary groups to get more involved in what we do and what we run. We will look to put the customer at the heart of what we do.

“And we will do this whilst we continue to do all we can to make Southwest One work. But I have to be clear; it is failing; it is inflexible; and it is intransigent. We are therefore looking at all the options available to us.

“I do have one final message for Southwest One – and that is to the staff and our Somerset County Council colleagues and secondees working there.  The message is this: This continuing failure is not about you. It is about the contract, the complications, the failed technology, the missed opportunities, the lack of promised savings.  It is about Southwest One itself, not about the people working for it.”

Comments on Maddock’s speech

Some of the comments on the Somerset County Gazette website were apt. One said “Somerset County Council has finally come to accept what we, the minions, have known for years: South West One is a failure and a pretty expensive one…”

Another said

“At last SCC admits to what everyone in the real world knew from day one …”

Comment:

One of the lessons from IT disasters in the private and public sectors is that things often start to improve once the main parties own up to the seriousness of the problems. The good news, perhaps, is that Southwest One may now be at its lowest point. It has at long last purged its bowels, so to speak.

Ian Liddell-Grainger’s website.

Southwest One gets £10m IBM amid “staggering” losses.

IBM struggles with SAP two years on – a shared services warning?

US Government to send in troubleshooters to sort out underperforming IT projects

By David Bicknell

The US Government wants to formalise a plan to send in specialist troubleshooting teams to rein in failing IT projects.

Federal chief information officer Steven Van Roekel  said the Office of Management and Budget (OMB) – which oversees the preparation of the US federal budget and supervises its administration in government agencies – is to create government-wide teams to take on the most problematic IT programs.

VanRoekel said agency CIOs also will continue to run TechStats, a government wide tool to shine light on and turn around underperforming IT projects. The critical details of a project’s health that are generated by a TechStat session reveal project strengths and the potential weaknesses that could lead to catastrophic failure.

As well as TechStats, VanRoekel said he will formally launch IT SWAT teams according to a US report.  The concept has already been used to help the Office of Personnel Management sort out its struggling USAJobs.gov portal.

“We assembled a team of the best and brightest IT people across government and they evaluated the USAJobs infrastructure,” said Van Roekel. “They sent me back a bunch of recommendations we now are having OPM implement and take forward. It is a great program and I’m excited to take that concept government-wide.”

VanRoekel said the goal is to bring together other teams of experts throughout 2012.

Links

Ian Watmore: ‘Majority of projects go very well and the public never hears’

Will the BRICS learn the lessons from developed nations’ limp track record of IT project delivery?

By David Bicknell

There’s not much doubt of the hot spots for IT spending over the next few years:  the BRICS.

According to this piece on ZDNet, while Europe remains transfixed viewing a Greek tragedy, other countries, notably the BRICS, are pushing ahead in terms of IT spend. 

Research firm IDC suggests that total IT spending will grow 5 percent in 2012 with emerging markets, smartphones, storage and software at the head of the pack.
 
Although European IT spending is likely to remain weak for the foreseeable future, spending in BRIC countries (Brazil, Russia, India and China – this seems to exclude ‘the S’ of South Africa) will see double-digit growth rates:
 
  • Brazil IT spending will rise 9 percent;
  • Russia will increase 11 percent;
  • India will  be up 16 percent;
  • And China’s tech spending will jump 15 percent

That spending means we can expect large increases in new IT projects – or perhaps I should say business projects delivered through IT.

Will the BRICS do a better job of the project management and delivery of these IT projects than we’ve managed in the developed world? Well, let’s just say there’s plenty of useful best and worst practice for them to take on board.

Links

Russia last in BRICS for faith in business

Can Brazil drive innovation?

Veterans Affairs lines up contractors for landmark health records IT project

By David Bicknell

A US IT project is being developed to provide  US military veterans with instant electronic access to their health and benefits information and other services.

According to Federal Times, the Veterans Affairs Department is now working with companies it already has on a $12 billion information technology contract to help it develop the Virtual Lifetime Electronic Health Record (VLER)

Last July, Veterans Affairs awarded 14 contractors, including CACI, Harris and Hewlett Packard Enterprise Services, a place on the departments Transformation Twenty-One Total Technology( T4) programme. The 15th and final spot is reported to have gone to SAIC.

Under the “five-year indefinite-delivery, indefinite-quantity task-order contracts”, vendors will provide program management and strategy planning, systems and software engineering, and other support.

The T4 contract has already been the subject of multiple bid protests – presumably because it appears so lucrative – including one filed last year Standard Communications in the U.S. Court of Federal Claims.

According to Federal Times, “nearly 39,000 US military veterans in 12 regions across the country — including Indianapolis, Richmond, and San Diego — have signed up to have their health information shared electronically among the Veterans Affairs, the US Department of Defence (DoD), and private health care providers.

“When participating veterans receive care, their physicians can request their laboratory results and other health data using the Nationwide Health Information Network (NwHIN), a project led by the Health and Human Services Department to provide a secure, standards-based method of sharing health information over the Internet. However, veterans must first agree to have their health information shared.”

The next project milestone for VLER will be this summer when Veterans Affairs and DoD decide how to expand health information exchange pilots nationwide.

Will the project succeed? It’s too early to say, although there are already some suggestions that the project has too many mouths to feed. One comment on the story so far argues that (the project) “has way too many contractors and staff involved. As we say, there are too many chiefs and not enough workers. It’s my bet that we will be talking about the 100 million dollar failure of the EMR at the expense of the US Taxpayers with in the year. They aren’t even getting the right type of people involved in the process. This is mainly a group of systems geeks and executives. They are leaving out the Health Information Management Professionals and the Medical providers…. it’s a boon doogle from the start, but at least the contractors are making money.”

Links

VA announces expansion of Virtual Life Electronic Record

10 Lessons Learned from Linking VLER to private health orgs

Veterans Affairs CIO on VLER progress

Why effective project management should focus on people, not just processes

By David Bicknell

I recently read an interesting post in the Gallup Management Journal which argued that when it comes to project management, most organisations put their practices before their people.

In other words, they place more emphasis on ‘rational’ factors, such as the process itself, and rather less on emotional drivers that could actually deliver project excellence – actually, just a project success would do! – such as their employees’ engagement with the project and company.

The piece, by Benoit Hardy-Vallee, points out that, “Project management is integral to the business world. Milestones, kickoff meetings, deliverables, stakeholders, Gantt charts, and work plans constitute the everyday world of most managers, whether they are called “project managers” or not. Given the vast experience organisations have with project management, it’s reasonable to wonder why all projects aren’t completed on time, on scope, and under budget.”

It argues that cost and time overruns on IT projects have had a profound effect on national economies, and suggests that one estimate of the IT project failure rate is between 5% and 15%, which represents a loss of $50 billion to $150 billion per year in the United States. In Europe, although the figures look pretty dated, they are still staggering in size: IT project failures  cost the European Union €142 billion in 2004.

What’s more, the piece argues, this trend is here to stay. With an ever-growing need for accessible and integrated data, organisations require larger platforms to manage supply chains, customer relationships, and dozens of other crucial systems.

“Mega-software projects are now common in private and governmental organisations, and development is not slowing down, especially in emerging economies.”

The blog argues that large projects, especially those in the IT sectors, already have a poor record. And forcing team members to adapt to project management processes and procedures only makes it more likely that the project will fail.

It goes on to suggest that a different, more powerful behaviour-based project management might be a better way of  enabling project groups to gain higher levels of emotional commitment and performance from their team members, as well as increased levels of emotional involvement from stakeholders to help improve both engagement and performance.

“A typical project management approach focuses on processes, policies, and procedures. Every task and step is described in detail by a set of rules.  Many companies implement rigid processes that dictate behaviour and use statistical methods to control quality (such as total quality management, kaizen, lean management, and Six Sigma). Process guides and rulebooks support work practices, while quality control systems assess and improve these practices.

“The problem with a single-minded focus on processes and methodologies is that once people are given procedures to follow, compliance replaces results. Everybody is concerned about how to do the job, not about the outcome if the job is done well.

“Companies that take this approach do so for valid reasons: They can’t manage what they don’t measure. More importantly, they can’t let projects run without any direction, hoping for the best. However, by relying on managing only these rational factors, organisations fail to harness the power of human nature by engaging employees’ emotions.”

The article concludes: “It’s time to update project management not with more methodologies, but with more emotional content. Employees’ and stakeholders’ disengagement can make a project fail, but behaviour-based management can make projects succeed.”

Gallup Management Journal

Bridging the divide: an engineered approach to IT projects

The State Auditor in California recently criticised a planned high speed rail system between San Francisco and Los Angeles because the project suffered from critical, on-going oversight problems. In this guest blog, Bob Evans, founder and Managing Director of TestIT Software Assurance, explains why it is critical to have a ‘single source of truth’ for any IT development, to provide the required level of cohesion, discipline, control and transparency that should be expected from any engineering project.

The risks associated with developing or changing IT systems are well documented. IT failures always bring despair and reputational damage to all involved.

Do you remember the scene in Blackadder where General Melchett suggested that walking slowly (again) towards the German machine guns would be “the last thing they’d expect” – and so “that’s what we’re going to do”? This seems to be the attitude found in many IT procurements. What’s needed is a fresh, radical and innovative approach, especially in these changed times where senior management focus is on delivery and cost.

Keeping Control

Establishing and maintaining control of an outsourced project is the single, most important part of IT development; it is imperative for the purchaser to remain in full control at all times. In all of the failure scenarios that we have researched, it is obvious in every case that control has been lost, with always calamitous consequences.

The nature of the procurement process and inevitable time pressure means that the requirements of a new software system aren’t always well-defined at project inception. Typically, specifications are incomplete or ambiguous and put together from a range of disparate sources, with non-existent internal process and control. The “silo” attitude that is often encountered across departmental organisations is usually a key factor here.  Requirements that are not made clear at the start of the project will inevitably lead to confusion, delays, additional cost and even to dispute.

And if a contract is awarded on the basis of a flawed specification, the chosen vendor is in a strong position to justify delays and ramp up the costs. When planned schedules are missed and costs spiral out of control, well intended remedial actions can then create new, unforeseen problems, leading to even more rework.

The culture of care and diligence found in many traditional engineering environments is sometimes lacking in the IT industry and in our experience, engineering discipline is usually the first casualty when pressure is applied. Very quickly, the focus shifts to fire-fighting and a project loses sight of its objectives. It’s like building a bridge – but when halfway across, only fitting every other bolt.

 Contrived Tests

It’s no surprise that applications that have seemingly passed an Acceptance Test, when deployed on a live system, prove to be problematic. Validating the effectiveness of an IT system is typically a contrived process – put simply, tests are designed to pass! They would be – they are usually designed, controlled and often even run by the software vendor.

If you were buying a used car from a local garage, you’d get the RAC to come along and check out the mechanics. You wouldn’t even think of asking the mechanic who worked at that garage to do the inspection would you? But invariably this is the case in IT.

As discussed above, it is imperative that full control of the project remains with the purchaser. But without, continual up to date feedback and independent metrics, it’s hard to know what’s really going on. And the critical decision – when to go live – cannot be made with confidence.

Agile Development

The concept of Agile Development has been round for many years. However, it is still to be seen whether this approach can really work on a large, complex project. A properly managed set of sprints – with precise objectives, proper controls and diligent, independent validation at appropriate times may indeed lead to a more rapid and successful conclusion. However, it should be noted that as development continues, the needs of the business will necessarily change. If controls are not adequately maintained, no process – not even “Agile” ones – can keep up. What is delivered is what the vendor believes is required, rather than what is actually required by the business. And no matter what methodology is used for developing software, at the end of the development cycle it is essential to verify, independently and thoroughly, that the product meets the needs of the business.

The Agile Manifesto focuses on “working software over comprehensive documentation”. Documentation is of course often cumbersome. However, minimising the amount of information while maximising the value of the information is what’s really needed.

When it’s too late – and organisations end up mired in a legal dispute, we’ve been called in to play the part of the pathologist. It is soon apparent that the project was doomed from the start – no spec, no metrics, no control, no hope. Suppliers who didn’t listen, purchasers who didn’t actually know what they needed in the first place.

But there is another way. The Maritime and Coastguard Agency recently used independent software assurance to ensure success of its high-profile CERS/SVD project. There was an acknowledgement right from the start that requirements were bound to change and controls put in place to manage this. There were efficient, timely tests – not at the project end, but continuous tests, right from project inception. There was an approach that asked:  “What can we do given the available time and budget?”, rather than the popular “one-shot, whistle and bells” approach. And there was pro-active searching for and identifying issues early on – when the supplier was still on site – which meant that remedial actions were fixed by the supplier, at no additional cost to the project. Independent, constantly updated metrics also meant that the Maritime and Coastguard Agency stayed in complete control.

It isn’t rocket science. But for IT projects, the discipline driven by an engineering-based approach is generally more likely to lead to success. That’s why bridges get built – and IT projects often don’t. 

TestIT Software Assurance

BRICS countries face identity card IT project delays

By David Bicknell

Two of the BRICS countries are wrestling with project management challenges as overambitious IT projects face an uncertain future.

India and Russia, which are two of the emerging so-called ‘BRICS’ – Brazil, Russia, India, China, South Africa – nations have implemented large identity card schemes which are now facing implementation hurdles.

In India, an ambitious biometric identification scheme for 1.2 billion people faces is likely to have to be redesigned if it is to survive.

The Asia Times says the Indian government has budgeted US$603 million to give a 12-digit number to each of 600 million residents by March 14, 2014, in the first two phases of the  project, dubbed “Aadhaar”, which means “foundation” or “support.”

The Asia Times says the Indian government had asked the Unique Identification Authority of India (UIDAI) project to enroll 200 million people by January 2012, in a first phase.

The UID number, which is set to prove identity, though not citizenship, would be supported by biometric devices such as facial recognition systems, eye and fingerprint scanners. However, a committee in the Indian Parliament has questioned its practicability and credibility.

The Standing Committee for Finance also challenged the legality, quality of technology and potential misuse of the UID information collected over the past two years.

The project had “no clarity of purpose,” observed the 48-page report from 53 parliamentarians, “and it is being implemented in a directionless way with a lot of confusion”.

It concluded: “In view of the afore-mentioned concerns and apprehensions about the UID scheme, particularly considering the contradictions and ambiguities within the Government on its implementation as well as implications, the Committee categorically convey their unacceptability of the National Identification Authority of India Bill, 2010 in its present form. The data already collected by the UIDAI may be transferred to the National Population Register (NPR), if the Government so chooses. The Committee would, thus, urge the Government to reconsider and review the UID scheme as also the proposals contained in the Bill in all its ramifications and bring forth a fresh legislation before Parliament.”

Meanwhile in Russia, according to the Moscow Times, a universal electronic card is facing delays, with a rollout scheduled for this month now being pushed to January of 2013.

The card – a combination of an electronic ID, driver’s licence, car insurance certificate, ATM card and migration document, among other possible functions – is the result of a project the government estimates will cost as much as 150 billion rubles to 170 billion rubles ($5.2 billion to $5.6 billion) to put in the hands of every citizen.

Limited initial use of the card was scheduled to take place this year, but the law that set up the project was amended in December to allow for a one-year delay.

The Moscow Times reported that the program will begin to function next year and that this year will be spent organising sites that will receive applications for the card. Application sites are expected to be set up at post offices, banks, and other locations.

A ministry spokesman confirmed that infrastructure for the project is just beginning to be created, and only four out of 83 regions having begun work on it.

“The delay in starting the project is related to issues around interagency cooperation and underdeveloped infrastructure in some regions,” said Yulia Kuchkina, a spokeswoman for the Universal Electronic Cards company (UEC). “Pilot cards are being issued — with employees of government agencies and ministries becoming the first users. In Moscow test cards have been received by employees of the Moscow Department of Information Technology,” she added.

Mail Online India: Setback for Planning Commission as Prime Minister bats for UID

Standing Committee for Finance Report

Some good IT project news from America

By David Bicknell

It’s always good to be able to write about IT project success. So I’m following up on Steve Kelman’s report in Federal Computer Week in the US about an October 2011 GAO report called Critical Factors Underlying Successful Major Acquisitions, which details seven recent government IT systems acquisitions – costing from $35 million to $2 billion – that have met their targets in terms of schedule, cost, and performance.

Aside from its conclusions on the critical success factors, the report says this about Agile software development: 

“….the use of Agile software development was critical to the success of the program. Among other things, Agile enhanced the participation of the end users in the development process and provided for capabilities to be deployed in shorter periods of time.”

As Steve suggests, the report should get wider circulation to show us what we might learn from success instead of from failure.

We’d be interested in your views.

Lifting the lid on Agile development within a public sector IT project

By David Bicknell

It’s not often that you get an insight into the workings of Agile development within a public sector  IT project.

So the Inspector General’s report into the Sentinel IT project at the FBI that I mentioned a couple of days ago offers a rare and unique picture into how the sprints, story points etc are progressing. This will not be new to Agile exponents – but the detail below may be of interest to those unfamiliar with Agile’s processes.

Transition to an Agile Development Approach

The report’s discussion of Agile within the Sentinel project says this:

“Agile software development is not a set of tools or a single methodology, but an approach that leverages close collaboration between representatives of system users, system developers, and testers to deliver functionality in a compressed timeframe and on a continuous basis. The delivery of working software is the primary measure of progress, and satisfying customers through the delivery of valuable software is treated as the highest priority during development.

“While an Agile methodology can be implemented in a variety of ways, the FBI is implementing a variation called Scrum, an iterative methodology which breaks the development effort into increments called sprints, each of which the FBI decided would last 2 weeks.

“At the conclusion of each sprint, User Stories – functions that a system user would typically perform – along with Architecture Stories – qualities that define the system software architecture and configuration – are planned and completed, and it is the successful completion of these stories that is measured as progress for the project.”

Development Progress

“As of August 26, 2011, the FBI had completed 22 of 24 planned sprints. Under the Scrum approach, a project’s progress and amount of work remaining is measured using a burndown chart, which depicts how factors such as the rate at which a development team completes work (a team’s velocity) and changes in a project’s scope affect its likelihood of staying on schedule and within budget over time.

“This information can be used by project management and project stakeholders to estimate the duration of the project or the amount of work that can be completed within an identified amount of time.

“During the first 22 sprints (Sprint 0 through Sprint 21), the FBI had completed 1,545 of the 3,093 story points (1,548 remaining) that it identified at the beginning of the project, or about 50 percent.  As of December 2, 2011, the FBI reported that it had completed 28 of 33 planned sprints ….It had also completed 2,345 story points  – 748 remained to be completed.”

Velocity

The Report says this of the Agile team’s velocity:

“According to FBI officials, after five sprints have been completed, the velocity, or rate at which an Agile team completes story points, can be used to project the completion rate of future work. During Sprints 5 through 21, the Sentinel team’s average velocity was 80 story points per sprint.

“During our review, we estimated that if the team’s velocity remained at 80 story points per sprint, the FBI would complete about 55 percent of the intended functionality by the end of the project’s originally planned 24 sprints on September 23, 2011. At that rate of development we estimated that Sentinel will be completed in June 2012.

“On September 6, 2011, the FBI CIO stated that the FBI had added six development sprints to Sentinel’s development schedule and that the FBI then planned to end development on December 16, 2011, after 30 sprints. After development ended, the FBI planned to test Sentinel for about 6 weeks and then deploy the system to all users in January 2012. During the additional development sprints, the FBI planned to finish the functionality work that it previously planned to complete by September 23, 2011.

“Based on the average velocity of 80 story points per sprint, and the number of remaining story points to be completed (1,548) we estimated that the FBI would complete about 71 percent of the intended functionality by the end of the project’s 30 development sprints on December 16, 2011.

“On December 1, 2011, the FBI again extended the schedule for the completion of Sentinel. The CTO stated that the FBI had added four development sprints to Sentinel’s development schedule and that the FBI now plans to end development in February 2012, after 34 sprints. After development, the FBI plans to test Sentinel for about 12 weeks and then deploy the system to all users in May 2012. During this testing period, the FBI plans to test Sentinel’s hardware and execute a test of all major Sentinel functionality that will involve personnel from across the FBI.

“Also in December 2011, after the FBI received a copy of our draft report, the FBI reported to us that during Sprints 5 through 28 it had completed 2,167 story points, an average of 90 story points per sprint – 10 more story points than its average rate as of September 2011.

“Based on this average velocity and the number of remaining story points to be completed (748) during the final 5 sprints under this plan, the Sentinel team must increase its average velocity to approximately 150 story points per sprint.

“However, the six sprints between the end of development and deployment – during which the FBI will test Sentinel – could also have story points assigned to them that the FBI is not accounting for at this time, and as a result the total number of story points to complete the project could increase. Without including such an increase, the FBI would need to average about 68 story points per sprint over the total 11 sprints remaining before the planned May 2012 deployment.”

Sentinel Agile Development Approach

The report’s Appendix says this about the FBI’s approach to its Agile development for Sentinel:

“In October 2010 the FBI identified a total of 670 stories for the Sentinel Product Backlog, or the compilation of all of the project’s stories. The FBI has mapped the Product Backlog to each of the requirements in Sentinel’s Systems Requirements Specification (SRS), which serves as an important control to ensure that the backlog, and the stories it contains, cover all of Sentinel’s requirements. The FBI also assigned weighted amounts, or “story points,” to each story in the Product Backlog based on the difficulty of the work associated with each story. The FBI assigned a total of 3,093 story points to its 670 stories in the Sentinel Product Backlog.”

The Report’s Conclusion

Although it appears that the FBI has made good progress with its Agile development, adopting Agile may not be enough to get the project exactly on track, with some testing issues and hardware problems discussed in the report.

“It is too early to judge whether the FBI’s Agile development of Sentinel will meet its newly revised budget and completion goals and the needs of FBI agents and analysts.

“While the Sentinel Advisory Group responded positively to the version of Sentinel it tested, results from wider testing were not as positive. Also, none of the Agile-developed Sentinel has been deployed to all users to give them the ability to enter actual case data and assist FBI agents and analysts in more efficiently performing their jobs.

“Despite the FBI’s self-reported progress in developing Sentinel, we are concerned that the FBI is not documenting that the functionality developed during each sprint has met the FBI’s acceptance criteria. Our concerns about the lack of transparency of Sentinel’s progress are magnified by the apparent lack of comprehensive and timely system testing.

“Our concerns about the lack of transparency also extend to Sentinel’s cooperation with internal and external oversight entities, to which Sentinel did not provide the necessary system documentation for them to perform their critical oversight and reporting functions.

“We believe that this issue could be resolved, at least in part, with a revision to the FBI’s Life Cycle Management Directive to include standards for Agile development methodologies.

“….Sentinel experienced significant performance problems during the Sentinel Functional Exercise. The FBI attributed these performance problems to either the system architecture or the computer hardware.

“According to the FBI, subsequent operational testing confirmed the inadequacy of the legacy hardware and the requirement to significantly expand the infrastructure before the system could be deployed to all users. In November 2011, the FBI requested that Lockheed Martin provide a cost proposal for this additional hardware.”

The FBI’s Response

In its response to the report, the FBI says:

 “….we are mindful of the short delay we have recently encountered under our new” Agile” approach. The Sentinel development schedule has recently been extended by two months (from December 2011 to February 2012), and the FBI-wide deployment is now scheduled for May 2012, as described in this Report.

“This modest extension is due primarily to the need to implement a standard  five-year “refresh” of computer hardware, so the Sentinel software will provide the required functionality as intended. Indeed, you have determined that, given the pace at which the program has proceeded under the Agile approach over the time period you reviewed, your estimate for completion is essentially the same – June 2012.

“We have one concern with the current draft of the Report. We request that you note that the hardware we are acquiring for the refresh, which is being purchased using fiscal year 2012 operations and maintenance funds, is separate from the development activities being carried out by the Agile team under the development budget.

“The refresh is part of the normal and expected operations and maintenance activities of the FBI, and such a refresh is a common maintenance activity where hardware has reached its expected replacement threshold. We do not agree that the FBI is using operations and maintenance funds for the development of Sentinel…and we ask that you make this revision.”

Will companies be counting the cost of DIY IT in 2012?

By David Bicknell

I enjoyed this piece by Susan Cramm commenting on what she calls ‘DIY IT projects’ where business executives think they can meet their technology needs more efficiently by circumventing IT.  She suggests that these are almost always a bad idea, but adds that killing the project can be worse.

As she argues, ‘nobody wins in these do-it-yourself projects. The executive who sponsors the project puts his or her reputation on the line by promising outcomes dependent on technologies that he or she is ill-equipped to develop, implement, or manage. The IT executive finds him – or herself powerless, relegated to integration and support tasks without having had adequate resources and time allocated for the project. Meanwhile, the CFO watches dollars flying out the window as the budget for ill-conceived and poorly executed initiatives becomes a moving target.’

With managing consumerisation arguably the hottest topic for IT organisations, I wonder how many business (IT) projects that don’t effectively involve IT will turn out by the end of the year to have been failed projects that in today’s austere times, their companies can ill afford.

ConsumerizeIT