![\"Productivity\"](\"https:\/\/www.mrc-productivity.com\/blog\/wp-content\/uploads\/2010\/11\/Productivity-e1291070228913.jpg\")
Many IT departments have developed a reputation of being slow and difficult. They make users jump through hoops and then take months to deliver requested solutions. The business users often feel like IT stands in their way, or even holds them back. <\/p>\n
The problem is, business users now have other options. Many are bypassing IT altogether and using unsanctioned SaaS options to accomplish their goals. If IT can\u2019t (or won\u2019t) deliver solutions in a timely manner, they find another way.<\/p>\n
IT departments have no choice: They must become more agile and responsive to the business user\u2019s needs, or risk being bypassed. <\/p>\n
The question is…how? How can a slow IT department become more agile and responsive?<\/p>\n
We posed that question to a few industry experts, who delivered some excellent advice. You can read their tips below, as well as some of my own. I hope you find them useful:<\/a><\/p>\n As mentioned in this recent article<\/span><\/a>, the importance of good application architecture cannot be overstated. Good architecture offers the flexibility necessary to add new features\/capabilities on the fly and rapidly adapt to changes–a critical component of agile IT departments.<\/p>\n This is where many companies run into problems. They run their business on an outdated system that\u2019s difficult to maintain. Adding new features takes months. <\/p>\n But, here\u2019s the sad truth: Without the right architecture in place, you will constantly struggle to meet your user\u2019s needs. You\u2019d love to deliver the applications they need, but with your outdated architecture, it will always be unnecessarily difficult and time-consuming. <\/p>\n Worse yet, this ultimately forces end users to make a decision: They can wait for months while you build their solutions, or they can take their credit card, sign up with a SaaS solution, and be up and running in days. Which do you think they\u2019ll choose?<\/p>\n A development platform gives you a centralized location to create and manage all applications within your company. It lets your IT department deliver applications quickly, control user access, and also provides self-service options for the end users. <\/p>\n “When the IT group adopts a strategy built around a robust development platform it is able to respond to the needs of the business more rapidly,\u201d says Tyler Wassell, Software Development Manager here at mrc<\/span><\/a>. \u201cA good platform should automate routine development tasks associated with coding, testing, and deployment but be flexible and open enough to allow maximum developer customization. Through this automation, developers are able to focus less on low level coding and technical tasks and focus more on application design and business requirements.”<\/p>\n Creating a truly agile IT department requires constant communication between IT and the business. Adam Ely, co-founder of Bluebox Security<\/span><\/a>, explains how IT needs to approach communication: \u201cEngage with your business users directly for feedback on areas of improvement and analyze how those improvements can be made either through technology and or policy.\u201d However, while that sounds simple enough, communication often causes the most problems for companies. <\/p>\n How so? Sometimes the IT department has unwittingly created a \u201cculture of no.\u201d<\/span><\/a> They\u2019re more likely to reject user requests than attempt to help them solve their problems…which leads to users bypassing IT altogether. Or, sometimes the users don\u2019t properly explain (or don\u2019t know) what they need. Or, maybe IT and the business just don\u2019t use the same vocabulary.<\/p>\n \u201cThe stakeholders and the developers must speak the same language,\u201d explains Steven Lowe, Founder and CEO of Innovator, LLC<\/span>. \u201cAn ‘account’ in one department is called a ‘liability’ by another department, and an ‘obligation’ in yet another department, while to the developers they’re all ‘customers’. If the developers understand the business environment using the same terms as the users, then conversations will be fruitful and multiply. If not…\u201d<\/p>\n Lowe goes on to explain the importance of constant communication throughout the entire development process:\u201dSpending 3 months on a comprehensive up-front design complete with screen mockups, workflow process diagrams, and stakeholder signoffs is comforting. The developers then produce exactly what the document says (several months later), and everyone is happy.<\/p>\n Or they’re supposed to be. Sometimes they are, because nothing had changed in the meantime, but frequently the stakeholders are not happy. Not only can the business and thus application environment change significantly during the development phase, but more often the stakeholders’ understanding of what they really need changes. So you end up with ‘yes this is what we asked for, but now we realize it is not what we need’. Which is only slightly less appalling than ‘we got tired of waiting and went with a SaaS solution’.\u201d<\/p>\n The only thing worse than not meeting your user\u2019s needs: Delivering applications that meet your user\u2019s needs, without notifying your users or explaining how to use them. Sure, you may deliver everything the users ask for…but if they confuse the end user, they\u2019re worthless.<\/p>\n1. Create an agile architecture<\/h3>\n
2. Implement a standardized development platform<\/h3>\n
3. Improve communication between IT and the business<\/h3>\n
4. Improve user adoption through proper education<\/h3>\n