If you are wondering what Bimodal is, it’s a term used recently by Gartner to describe two different and complimentary facets of IT organizations. Mode 1 is traditional IT, where systems must be reliable, predictable and safe. Mode 2 is non-sequential, emphasizing innovation, agility and speed.
IT organizations need to have both modes of operation if they have any hope of responding to the pressures coming from the business. Social media, cloud computing, mobile, analytics and big data, and the internet of things are top of mind for business leaders. They know they need to be leveraging these technologies in the business, and need to do it now. Mode 2 IT is required to address these priorities in a fast and agile way.
In a Gartner survey, 45 percent of CIOs state they currently have a second fast mode of operation and, by 2017 they predict that 75 percent of IT organizations will have a bimodal capability.
So is your IT organization Bimodal? If not, Gartner warns that the business will not wait for you to put mode 2 into operation. Shadow IT occurs when an area of the business develops and deploys an IT solution outside of the IT organization. Shadow IT projects have been occurring for some time, however the frequency is increasing with the business pressures described earlier, and when the IT organization has no capability to address business needs with agility and speed. Shadow IT, done independently from the IT organization, can lead to security and integration issues that IT will inherit when issues arise.
Archetype SC brings speed, agility, and innovation to our customers. Let us assist you with your move to Mode 2 IT delivery.
If you have children or grandchildren like me, you’ve probably heard these questions on multiple children’s TV shows where the characters set off to solve some incredible mystery. They ask these questions to figure it out. One of the shows, I think The Electric Company, has a very cute song that repeats these questions over and over as the characters work to figure out the mystery. I chose to not research this and verify which show it actually is. I never want to hear that song again, since this is one of those songs that when it gets in your head, you can’t get it out. If you listen closely, you can hear it playing in my head right now.
In fact, it is so embedded in my brain, that when I was reading a series of white papers on how to gather and manage system requirements, it immediately popped into my head.
Here’s what triggered it.
“Good requirements need to be concise and specific, and should answer the question, ‘what do we need?’ Rather than, ‘how do we fulfill a need?’”*
This requirements gathering advice is not new, been around almost as long as I have. Even kid’s know about it, except they really need to leave off the “how”. The who, what, when, where, and why are right on target though.
This approach is so fundamental, that all the good requirements documenting practices and tools don’t matter, if the requirement is constrained by how that requirement is to be fulfilled.
If you are looking for someone who is a proficient in asking what and why, and will steer you away from the pre-conceived how, contact Archetype SC. We’ll design and build your new system focused on what you need to accomplish your business objectives, not how you do things today.
* Requirements Management 101, White Paper published by Jama Software
I recently spent time thinking about a software development project I’m managing that had me a bit puzzled. This is first time in my long experience in project management where there is absolutely no pushback from anyone in the business regarding the project. No one is questioning the reasons to do it, the scope, or the approach. The organization is clearly aligned and committed to getting the project done.
I’ve managed software projects for multiple fortune 500 companies, with 8 figure budgets and project teams of 100 plus members. There has invariably in every project been an individual or group that was either passively or actively opposed to the project. That is not the case in this project, so what is different?
I reviewed the “Top ten reasons why projects fail” lists to see if there were any clues to why this project is so different. I’d not looked at any of these lists for some time, and found it interesting how many different variations there are. The top two on my personal list are having a clear and well defined business case, and the importance of executive sponsorship for the project. My most difficult projects have been those where the business case was ill-defined and when executive sponsorship was missing. Most troublesome has been projects where the executive sponsor has changed, or when C-level executives, who are major stakeholders change. In these situations the business case is often questioned by the new leadership and executive support can disappear. When executive support wavers, passive resistance can turn active quickly.
Below is just one of the top ten lists I came across in my review, and number 1 and number 9 in this list match my personal top two.
The current project that breaks the mold with no one opposing the project has a business case and executive support, much like the majority of the other projects I’ve managed. Even with these in place, all the other projects still had a level of resistance.
So why is everyone across this business on board and actively supportive?
The conclusion I’ve reached is that it must be the “pain factor” that has everyone aligned. The system that is currently in place is very old and lacking in functionality. Business processes are very manual, error prone, and labor intensive. The pain in using the current system is widespread across the organization and constant. The entire organization is supporting the project that will ultimately make the pain go away.
My personal list of things that impact the likelihood of project success or failure now has a third major consideration, the pain factor. The higher the pain factor and the broader it is across the organization, the more likely the organization is to rally behind the project that will make it all better. Conversely, a project that is not going to impact the organization by relieving a painful situation, may not have as high a likelihood of success, even if there is a strong business case. When the pain factor is low, all the factors on the top 10 lists become more important.
Successful projects don’t just happen. They require attention to all the factors that can cause projects to fail or not deliver a quality solution to the business. Archetype SC can work with you to identify your top ten risks and the strengths of you organization that will mitigate these risks and insure success in your project delivery.
WHY PROJECTS FAIL – TOP 10 REASONS
Excellent Project Management post by Tom Tsongas. January 13, 2014.
- Lack of a Project Charter
- The Project Charter is essentially the ‘what’ portion of the criteria of the project. It dictates exactly what is being built, created or enacted and explains in high level terms the various justification and initial scope for the project.
- Lack of User Involvement
- Poorly Defined Requirements (Poor Scope Definition)
- Scope Creep
- Inadequate (or non-existent) Testing
- Lack of Resources
- Use of New or Unfamiliar Tools
- Political Infighting
- It exists in companies as well as governments. Functional managers and executives with their own vested interest in specific aspects of the business can often come to blows over new or existing projects.
- Poor Project Management
