Skip Navigation

Thought leadership from SAI to accelerate your performance

Systems Alliance Blog

Opinion, advice and commentary on IT and business issues from SAI
Date: Jan 2014

With Software-as-a-Service applications becoming the norm rather than the exception, we see many organizations facing the challenge of how to handle identity management and single sign-on for all of these new services while also supporting their internal systems. Unfortunately, most organizations find themselves falling into one of two camps. Those that adopted a solution a number of years ago find themselves struggling with one of the old legacy systems that are very costly to maintain and hard to manage. Worse yet, those without a solution in place are faced with providing the user with a long list of IDs and passwords that are not only inconvenient and frustrating for the user, but also create administrative nightmares and significant security risks.

The Outlook is Cloudy

Whether it’s Salesforce, Office 365, Google Apps, Box or others, proliferation of cloud-based services has developed much more quickly than ways to effectively manage access to them. This shift in the way applications are provided has left many IT organizations in a quandary.

Those with legacy systems are on a “connector treadmill”, doing custom development work to provide a connection to each cloud-based service when it’s required. Each of these iterations is costly, takes a lot of time and delays deployment of the new application or service. At the end of the day, this is a cumbersome solution at best.

Those that are facing the challenge without a solution in place are wondering what questions to ask and how to quickly get a solution in place before a security breach occurs.     

What Should I Be Asking?

Whether you’re at your wit's end trying to morph your high-cost legacy solution into one that is cloud aware or evaluating new solutions to address the identity management and single sign-on challenges, here are ten questions to include on your capabilities checklist:

  1. Was the solution built from the ground up to handle cloud-based applications as well as my on premise systems?
  2. Does the solution require a significant investment in my infrastructure in terms of hardware, software and technical resources?
  3. How many cloud-based applications and on premise systems are supported “out-of-the-box” to help me avoid the “connector treadmill”?
  4. Does the solution leverage a centralized directory (such as Active Directory or LDAP) that I already have in place?
  5. Does the solution automatically provision and de-provision user accounts? 
  6. In terms of mobility, does the solution offer a consistent experience on desktops, tablets, smartphones as well as desktops inside and outside of my network?
  7. Since a lot of my help desk calls are related to password resets, does the solution offer a self-service password reset feature?
  8. Will the solution show me who has access to what and when they use it?
  9. Does the solution hold up under the scrutiny of SOC2 Type II or equivalent independent audits?
  10. Is the solution easy and quick to implement with an impressive ROI?

Clearing the Fog

After researching various solutions available in the marketplace, Systems Alliance Inc. has partnered with Okta.  The Okta Identity Management solution increases security and control, improves user productivity, reduces IT costs and maximizes SaaS ROI. This solution is cloud-based, architected for zero downtime, supports thousands of applications out-of-the-box and can be quickly implemented (usually within a few weeks). ROI is also impressive since it doesn’t require any significant internal infrastructure or in-house engineering expertise.

Selecting a Solution is Only the First Step

Although selecting your identity management and single sign-on solution is a good first step, it’s just as important to have a smooth implementation. To that end, stay tuned for the next segment that will discuss guidelines, pitfalls to avoid and best practices when implementing these types of solutions.

Learn more about SAI’s IT Strategy and Operations services.

I was surprised to see a reference to Fred Brooks’ 1975 classic, The Mythical Man Month(1), in a recent blog post(2); it was suggested as required reading for those involved with fixing the problems with The blog focused on the idea that throwing additional staff at a floundering project is likely to make things worse.

For those unfamiliar with Brooks’ classic work, it presents lessons learned from his time as manager of the OS/360 development effort. I’m probably telling more about myself than I should, but I have a dog-eared copy in my personal library and think it should be a must read for all IT project and program managers. The book covers a host of risk management topics, most of which are as relevant today as they were almost 40 years ago.

Estimation: Consistent application of an estimating discipline that considers performance on prior projects is key if the risk of delivering projects over budget and behind schedule is to be avoided. Brooks highlighted the importance of considering the amount of time likely to be spent on administrative and other non-technical tasks rather than focusing exclusively on technical activities. He also argued that testing involves a greater percentage of project effort than managers and developers typically estimate at the outset. While estimating discipline doesn’t change the level of effort or time required to deliver results, it does provide a more reasoned view of what you can expect.

Progress tracking: Actively tracking and reporting project progress not only provides a primary source of data for future project estimates but also reduces the risk of major project delays and overruns. Defining interim milestones and monitoring progress against them is critical to success.  To paraphrase Brooks, “major project delays don’t happen at once, they happen one day at a time”.

Communication: While software development methodologies have evolved significantly since Brooks’ days, the need for stakeholders to have a common understanding of project objectives, core requirements, deliverables to be produced and key roles and responsibilities has not. Minimizing project delivery risks requires communication and documentation. Yes, documentation, the bane of most IT staffers, has an important role to play in successful project delivery.

Staff skills and experience: One of the development challenges that has been widely discussed in the press is the lack of a cohesive design; one that could accommodate the high number of users expected and enable delivery of a positive user experience. Some have suggested that the government would have done better by seeking assistance from top tier technology firms rather than relying on their traditional service providers. In The Mythical Man Month, Brooks cites the importance of conceptual integrity (i.e. design integrity) and the use of expert resources to lead both the overall design effort and the development of critical components.

Change management: On large projects where requirements changes are inevitable and design changes are a distinct possibility, a formal change management process is a critical requirement. On time, on budget delivery of a quality solution is jeopardized when the potential for change is not acknowledged and the process for handling changes is not clearly defined. Effectively planning for and managing change are themes that run throughout Brooks’ classic work.

While advancements in technology have enabled the delivery of many products and services that were unthinkable 30+ years ago, advances in project and program management discipline have lagged far behind. It seems that some of the lessons documented in The Mythical Man Month have yet to be learned.

Do you have any lessons learned from IT projects that aren’t listed here? Tell us about it in the comment section below. And as always, if you’re having difficulty with an IT project, we’re here to help. Get in touch.


(1)Brooks, Jr, F. P. (1975). The Mythical Man Month, Essays on Software Engineering. Massachusetts: Addison-Wesley.

(2)Yglesias, M. (2013). Obamacare's "Man Month" Problem. 

I was recently asked to help a friend revamp her résumé. Now this person is a highly successful software sales professional whose reputation in her industry precedes her – which is a good thing because her résumé stinks. No kidding. As I sat down to try to make sense of the three rambling pages in front of me, it occurred to me that my friend’s résumé exemplified almost every problem I warn clients about when we discuss their website content.

In many ways, an organization’s web content is its résumé. Both are substitutes for personal interaction, and success means getting past the clutter. It really comes down to branding....Read More

Jan 2014