Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

Sunday, April 13, 2014

IT Governance For Small Businesses - Constraints

There is a perception that IT Governance best suits for large organizations and small organizations tend to ignore it considering the efforts and resources that is required in practicing the IT Governance within. But IT Governance is equally important for smaller organizations as well, so that the IT function however small it is deliver maximum value for the business and at the same time to keep the risk exposure to the minimum. Existing frameworks like COBIT are too extensive for small businesses to use in implementing IT governance. These frameworks however are too complex and costly to implement and small businesses may consider it a bigger battle to implement and manage such framework.


ISACA however recommends to take an evolutive approach and thus take smaller steps first and let it evolve. Small businesses should convert the high-level concept of governance into practical and easy to implement best practices. The resource pools available with the small businesses will be a lot smaller and even outsourcing might prove expensive, considering the business volume and thus establishing an RoI on implementing IT Governance could be a bigger challenge.


It is not just the resources and cost, there are certain other characteristics of small businesses, which come in way of implementing an IT Governance. Here are some such characteristics, which an IT Governance framework designed for a small business should take into consideration.


Smaller or no Board of Directors

Many small businesses are closely held and thus could be a family business or private limited company with a small number of Directors on the Board. Having an Independent Director or a Director with IT background on the board is a big ask. This will leave the concentration of IT decision making with few or even single individual, which could be the CEO or the owner himself. IT savvy business owners or CEOs tend to use or leverage IT more for their business and thus have some degree of adoption of standards, practices and frameworks. In such cases, the choice of technology, standards, practices, etc are most likely limited to the knowledge levels of the owner or CEO and they don't take a leap forward into unfamiliar areas, which will call for more resources in evaluating and establishing the RoI for the same.

Organization Structure

One of the first step in implementing the IT Governance in an organization is to get an IT Strategy Committee and an IT Steering Committee with representation from different functions and from the Board. Small businesses do not have the extensive management structures to have such committee(s). The organization structure with small business are not as extensive as that of large organizations and as such enforcing separation of duties may not be feasible at all. For instance, the Finance Manager of a small business will also perform the function of IT procurement with minimal support from IT Administrators. Similarly, having a separate CIO could be a bigger ask for a small businesses as the costs for having such resources does not warrant the return.

Smaller IT departments

Having a fully functional IT department is a big investment for a small business. Thanks to the cloud trend and software as a service, this is a challenge even the IT departments in large organizations are facing. Cloud based services like Google Apps for business and Microsoft's Office 365, coupled with various specific purpose software as a service, it is becoming a lot easier for the businesses to get its IT up and running with least help from IT experts. This characteristic of a small business leads to a situation where a non-IT staff might have to take up the IT Governance initiative, which obviously has a challenge within as such staff might not comprehend the nuances of the Governance practices and jargon.

Lack of complementing frameworks

IT Governance  framework generally relies on various other practices or frameworks practiced in an organization. For instance ITIL, Enterprise Risk Management, ISO, CMMI, etc are some such standards or frameworks, the existence of which makes adoption of an IT Governance framework a bit seamless. In a small business existence of such standards is highly unlikely. Small businesses need an IT governance framework that is simpler, self containing and easier to implement, and only contain controls that are not dependent on a control practice of a different standard or practice.

Information security

While small business are not the target of hackers or attackers, the risk of information security always remained. For obvious reasons that arise out of the characteristics listed here, small businesses could not see the return on investment in information security. For that matter, small business do not have a formal risk management practice. They, typically, do not possess some of the basic elements of security management like information security policies, backup and disaster recovery, security awareness and up-to-date anti-virus protection. An IT governance framework aimed at small businesses will have to include a strong emphasis on information security and address the common security risks affecting small businesses.

Resources & Tools

Use of sophisticated software applications make implementation and practicing IT Governance easier, but it calls for heavy investment, which is beyond the reach for small businesses. For instance, Performance Evaluation of various IT resources call for collection of data and come up with various metrics that can be used to benchmark and as well measure the performance of IT resources and functions. This is made easier by using automated tools and depending on manual methods could prove cumbersome and data inaccuracy.
Because of the lack of financial and technical resources, small businesses cannot make use of such automated tools or software systems for the purpose.


Though the above list is not exhaustive, what are listed above are the ones that can be considered as key constraints for an IT Governance framework for the small business to address. There is no one solution fits all even for large organizations. The IT Governance framework has to be designed, created and managed as relevant for each organization. That includes even a small business. While one may pick and choose controls from various frameworks and tailor them to suit the specific small or medium business. The framework should however provide for evolution, so that the same can improve based on feedback from the practice.

Saturday, September 28, 2013

Strategies for Information Governance

No, we are not discussing about IT governance or Data Governance either. It is about Information Governance. Information is fast becoming the currency of the business organizations and it is an important asset that need to be protected, managed and governed. Physical records are giving way in favor of digital information and it is growing and moving beyond the boundaries of the enterprise. This opens up a new set of challenges in realizing the business value and managing the associated risks. To add to that a whole set of new and evolving regulatory requirements escalate the risks of privacy, security and retention. Now to understand what is Information Governance let us look at how Gartner defines it:

“The specification of decision rights and an accountability framework to encourage desirable behavior in the valuation, creation, storage, use, archival and deletion of information. It includes the processes, roles, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals.”

Looking at the above definition, we can say that the Information Governance is a framework for managing information life cycle from its creation through its deletion and defining accountability, retention, protection and quality aspects around the same. Obviously the framework should comprise of processes, standards, roles & responsibilities, metrics and tools and technology for effective and efficient use of the information. The framework should be in line with the strategies of the organization for Information Governance. So it is important to establish the strategies first and then build the framework around it.

Obviously the Information Governance Strategies shall be formed with due consideration to the following aspects of Information:

Classification: Information classification is one of the most crucial elements of an effective information governance process and yet it’s also the one that many organizations fail to implement well. In its simplest terms, Information classification is the process of categorizing information based on its level of sensitivity, perceived business value and its retention needs. While information classification based on sensitivity is mostly prevalent as most of the Information Security frameworks demand, for an effective and efficient information governance, the classification should represent the retention needs and the business value in addition to sensitivity. When done properly, the classification of information helps an organization determine the most appropriate level of safeguards, controls and usage guidelines that need to be in place. Organizations should be aware that data classification may change throughout the life cycle. It's important for data stewards to re-evaluate the classification of information on a regular basis, based on changes to regulations and contractual obligations, as well as changes in the use of the data or its value to the company.

Protection: Protection of data is an important Element of the information governance framework. Data security breaches now appear to be headline news almost on a weekly basis. The consequences can be
disastrous as organisations’ bottom line and reputation are impacted. Information management and protection is undoubtedly moving in keeping with organisational changes. A planned governance structure
for information allows organisations to support business expansion, while meeting regulatory and personal data protection laws. 

Retention: Organizations are obligated to respond to various information requests, be it litigation, audit or investigation. There are numerous legislations in various countries requiring retention of information for a certain period to be used as evidences. Certain countries have legislations that require non persistence of information, i.e. certain class of information not to be persisted for privacy reasons. Effectively balancing such complex retention requirements depends on proper identification and classification of the information and use of appropriate tools and technology.

Roles & Accountability: Historically, establishing robust information management was considered an IT challenge. The CIOs were expected to deliver the appropriate technology to support critical information reporting and management, and the CISOs, who are mostly aligned with IT functions, were expected to protect the information assets. This does not absolve the business functionaries from the accountability of the information that they create and manage. IT is just a facilitator and it is the business who owns and be responsible for the information throughout its life cycle. The overall requirements of any information asset must be specified, ultimately, by the business people who define, understand and own the process that handles its usage. 

Collaboration: The people who staff the functions that produce and use the information are the people who know its value, can point out the current version of documents, should know how long a given document or set of data is going to be useful from a business continuity perspective. Thus it is very important that their knowledge on these aspects of information is considered while formulating the information governance strategies. Committed involvement from every employee and an effective communication amongst all of them is the key in building a successful information governance framework. Continued collaboration of all the business and IT functions is also essential in sustaining the information governance program in the organization, so that various attributes that determine the information classification, its usage and its business value are constantly aligned to the changing landscape of regulatory and business needs.

Quality & Integrity: As the information is becoming a key asset of an organization and that many decisions are based on the information at hand, it is important that the quality and integrity of the information to be at the highest level, so that such decisions do not go against the organization. Appropriate processes or techniques to validate the quality and integrity of the information shall be put in place and those involved in the creation or discovery of the information shall ensure that appropriate checks are performed and ensure that the information so created is reliable.


Information Governance is a combination of business practices, technology and human capital for meeting the compliance, legal, regulatory, security requirements, and organizational goals of an entity. Information governance provides a means to protect, access, and otherwise manage data and transform it into useful information. While applying best practices such as physical and electronic security measures as well as creating policies for the disposition of data are critical to implementing an information governance strategy, available technology solutions and services can play a key role in several areas.

Saturday, January 26, 2013

Solution Architecture - Aligning Solutions with Business Needs

As the Enterprise Architecture & IT Governance adoption is on the rise, we keep hearing a lot about IT - Business alignment. ISACA positions Strategy Alignment as an important knowledge area along with five other knowledge areas. Enterprise Architecture being an important function in architecting or engineering the enterprise itself has a major role to play in appropriately deriving the IT strategy from the business strategy and ensure its execution as intended. Within the overall Enterprise Architecture function, it is the Solution Architecture function that acts as a bridge between Business Architecture and the Technology / Application Architecture. So, the Solution Architecture is a key role in transforming the business needs into IT solutions and it is this function that is key to ensure that the IT solutions are in alignment with the business needs and strategies.

Now, most of the Solution Architects are well aware of this important need at the early stage of solution design and Architecture, things keep going in the wrong way and the business in general are not happy with the solutions delivered. While most of the Solution Architects do well in the initial phase of the solutioning, somewhere down the line things tend to stray away and let gaps creep in resulting in a misaligned solution being delivered. A close examination of the causes of various misaligned projects reveal the causes which are listed below. This list is not exhaustive and is not in any order of priority.

Requirement Analysis

Typically a detailed Business Requirements Specification document is the input for the Solution Architecture function and the solution that the Architects propose largely depends on the veracity of this document. A good knowledge on the business domain of the organization in general and the ability to apply critical review on the requirements would bring out possible gas that if ignored might creep into the solution implementation leading to gaps. Needless to stress here is the non functional requirements, which on most occasions remain undocumented and a largely contributes for the gaps to creep in. Lack of formal processes that call for iterative reviews of the business case and in turn the requirements specifications is cause of concern.

Generally the Solution Architects should be engaged from the initial stages of problem definition, so that they will be in a position to gather the needed details, which might not figure in the requirement specifications.

Expectation Management

Traditionally, the business just throws in the problem they want to solve or the opportunity they want to exploit and probably participate in defining the requirements. Thereafter, they just leave it to the Architects and developers to do whatever and finally deliver the solution. In one of a project for a leading multinational bank, it so happened that when the solution was delivered, they reacted stating that this is not what we wanted and they found that the requirements specification as duly accepted by them was in total mismatch with what was expected. It is good and easier to have this expectation mismatch ironed out early on, before getting deep into implementation. While the expectation mismatch is generally on the non functional needs, like usability, portability, reliability, etc, at times, even the functional requirements also leaves room for misunderstanding by different teams leading to misalignment. The best way to address this area is to involve the business in the periodical reviews by using Agile practices. Even with Agile, this could happen if those representing the business do not have the same understanding of the business needs at large.

Validating the solution design with the business representatives and keeping a watch on the expected design outcome as the implement progresses for possible impacts on the expectation is the best way to address this concern.

Skill Gaps

Solutioning is not a pure science and one should be able to blend the science and art. Getting the best solution depends on the Solution Architects’ ability to visualize the final outcome given the constraints and choice of tools and making sure that this what the business would want. While the skill gaps with other related functions would still be a cause for concern, the deficiencies with Solution Architecture function could mean dear as they play a part early on in the life cycle.


Choice of Tools & Technology

While the choice of tools and technology is not generally within the domain of the Solution Architect, it is important to be knowledgeable of various tools and technology that can be leveraged within the constraints of the IT strategy will go a long way in proposing a best solution. Another concern around this issue is that as the Technical Architects or the development team encounter feasibility issues with a chosen tool or technology, the Solution Architect has to jump in again and align or tweak his solution to overcome such issues without impacting the expected final outcome.

Culture, Communication & Collaboration

While continuous review and monitoring would help bring out exceptions, it is for the organizaiton to nurture a culture amongst the teams so that everyone knows what is the business and IT strategy and the value of the work that they deliver towards IT solutions. The Solution Architecture team should have a thorough understanding of the IT Strategy and ensure that the solutions that they propose are in line with it. It is also important that the teams should collaborate well and work for the common objective of ensuring that the execution of the solution design progress in the expected manner and timely escalation of exceptions for appropriate action.

Roles & Responsibilities

Lack of clear definition of roles and responsibilities would lead to negligence in the deliverables by individuals and teams. As with a project I cited earlier, the business representative who approved the requirements specification did so without being sure of what he is approving. Further reviews and monitoring are very much needed to spot such lapses early on. The culture of the organization should also be such that the teams and team members own the problem and contribute for the solution to the expectation of the business.

Review and Monitoring

Depending on the size and strategic importance of the projects, the program and project management team should keep a watch on any potential impact on the expected outcome and exceptions if any observed are analysed for possible changes to the solution design and implementation and in turn managing the expectations appropriately. This would call for identifying the key goals and outcomes upfront and come up with appropriate metrics to keep track of.

Another area to keep a watch on are the assumptions, constraints and the dependencies which have been identified as part of the project charter. It would be impossible to iron out all ambiguities at the start of the project and as such it is a prevalent practice to start off by making assumptions on such ambiguities and proceed. However efforts should be on to get those assumptions validated and make them unambiguous as the project progresses. Any change in the assumption might trigger redesigning the solution. Same is the case with the various known constraints and dependencies with which the solution is designed and being implemented.


As we could observe all the stakeholders have a role to play in ensuring the alignment with business need. However, the Solution Architecture function sets it off and the other teams carry on from there. The Solution Architects should hold the key, being in close touch with the implementation teams, making themselves available for clarifications, being receptive to emerging issues around the solution design and coming up with needed improvement to the solution designs.

Related Reads:
Solution Architect - Understanding the role

Saturday, September 15, 2012

Leveraging Lessons Learned

Success = failure + failure + failure … Sounds familiar?


Leadership experts and management gurus have said enough about how failures lead to success. That is very true for the individuals when the respective person takes it in the right context and work on the causes of the failure to overcome it in the next opportunity. But how does this work in reality for the organization?
 
If you have been part of a project, which has failed to deliver the promised features on time or at the agreed cost, you are most likely out of that organization, as the management want to penalize those involved in it. In the process, the organization loses as it did not want to capitalize on the lessons learned by the team through the failed project and the new team that takes over might commit same or even different mistakes, which could again lead to failure. 
 
Agile projects are likely to fare better in this space as Agile project management calls for identifying things that went well and those did not went well at the end of every sprints. Here again the one question that remains to be answered is, how does the scrum master and the teams deal with the things that did not went well in the earlier sprint. Yet another question that needs to be answered is how open are the project team members in openly admitting their own errors and omissions, which could have adversely impacted the project. 
 
 
As far as the development teams, there are so much to be learnt on a daily basis, for example, the defects uncovered in unit testing, findings in the requirements, design and code reviews and even the project issues could lead to a great lesson to be learned by every other member of the team. 
 
 
Here are few ideas that will help the organization in leveraging the lessons learned by the teams through various errors, mistakes and omissions.
 
  • Mentor the teams to the effect that they demonstrate accountability and responsibility and that admitting a mistake early on is a good thing. The earlier, the triggers are known, it is better as other members of the team would stay away from committing the same mistakes.
  • Coach the teams to share, share and share with their peers and even across the teams. This can be accomplished by removing the mind blocks within the employees in admitting their own mistakes and they should be encouraged to share those for the good of themselves and the organization. It is the tendency of the employees that when they uncover any issues during unit testing and reviews, they would just fix it themselves and do not report it further.
  • Encourage teams to share their previous experiences every now and then and for sure there will be some takeaways from such experiences for some members of the team.
  • Bring in a culture within the organization which will discourage egos and emotions which are found to be the barriers for sharing.
  • Promote risk management and encourage every employee to participate in it. It is needless to say that every identified risk has the potential of becoming an issue and soon can come in way to prevent the project from being successful. Past experience and lessons learned is a great source of risk identification.
  • Above all, make the sharing the lessons easy by putting in place an appropriate knowledge base platform and train and encourage employees to use it.
 
Though the above ideas are more suitable for IT services organization, they can be practiced in any other organization as well with some tweaks.
 
Here is an interesting article to read on, where in Ken Bruss discusses about leveraging lessons learned for competitive advantage.

Friday, August 17, 2012

Taking over - stay away from wrong battles

 If you are about to take up a Senior Managerial role in an different organization, it is important that you are able to settle down at the right pace and pick up the right battle to make a mark in the first few weeks of taking over. While it is true that the management has through multiple rounds of discussions have tried their best to understand your abilities and have got convinced that you are the person to take the organization further down the roadmap, there could be challenges which you would not have faced before and you should take little care about few things like the following.

The takeover session
 
 
Usually, you might have a chance to have few rounds of discussions with your predecessor as part of the handing over process. It is important to use this very effectively. Among other things, the important items to pick up in this session are 
  • Get to know why your predecessor is leaving, and this would help you to plan and carefully handle such pain areas so that you also don’t end up getting into a battle.
  • Get to know from your predecessor as to his opinions about people, process and technology in the organization and this would give you certain handles to pick up and carry on with.
  • Get to know as to what he has been upto in the past three to six months period so that to understand his unfinished initiatives and if certain initiatives failed why so. This will help you to understand the various constraints with which he has been operating and most likely those constraints would hold on for you too to deal with.
  • Get to know about the strategy, vision and goals of the organization and the roadmap to achieve those. It might be possible for you to identify certain areas to work on, but again don’t jump into action plans you need to get 360 degree view of the issues.
 
 
Just in case, you don’t have this opportunity of a smooth hand over, try to get same inputs from the next level executives, but use such inputs with care as you might want to validate the same from few other sources.
 
 
The Cultural Values
 
 
Each organization has its own culture that suits the most for the teams and the business. As part of your taking over, it is important that you understand he organizational culture, the morale of the employees and if required you may spend little more time to make yourself a fit into the prevalent culture and gain the confidence of the teams. While there is a chance that the given culture could be the cause of certain pain points and may need a change, you may not want to pick up such battles so soon as it could lead to the teams not accepting you as a leader. As you might have come with a different cultural background, it is so easy for you to get carried away and make missteps.
 
 
Spot the problem areas and the pain points
 
 
While you would have got to know some of the priority areas that need immediate attention, before jumping into action, spend more time to talk to various teams to understand completely as to the current state of various projects and initiatives that they are upto. Depending on your approach, style and your experience, you would spot certain pain points that need attention. Capture those for later action. Sooner you identify those it will help you to settle down quickly. It would also be a good idea to spend some time in understanding the failed projects or initiatives in the recent times, which would help you pick up certain process areas to revisit and work on. You might have to use your tactical and people skills here so that the teams open up to you freely and you get a good handle of the areas to work on.
 
 
Perform a careful analysis of these items for their impact on other aspects like, culture, process and technology which will help you to categorize and prioritize these areas and come up with a revised roadmap for the near term and the longer term.
 
 
In the process of settling in, it is very much likely that you will try to use your experience and suggest course correction or jump into actions in the middle, which if not done well could land you into trouble as might start facing resistance from some quarters. Though these could be overcome with authority, it may not work well if you use it early on. In such cases, you should be convincingly demonstrate to such teams that the course correction is much needed given the situation and take them into confidence that way. Picking up wrong battle early on could prove costly.
 
 
As many leaders say, a good leader is a good listener. So listen more early on to get to know the perspective better and try to pick up some lessons. For a while, you should forget your experience and expertise and try to be a learner and keep listening. Once you are done listening, do an alnalysis and in that process, you may use your experience. Keep in mind that there is no single best way to accomplish a thing and there could be multiple ways and means and it could be so that you might have a chance to pick up certain new things that might work well too.
 
 
Please understand that this is not a complete guide for you to just practice blindly. This could be completely out of context in some situations and may not hold good at all. However, what is to be taken out this is that try to stay away from picking wrong battles early on.