Wednesday, October 7, 2009
Tuesday, September 15, 2009
How to Deliver Successful Projects: Have a Dialogue
Talk, talk, talk, and then ... talk some more. You cannot talk enough when you're leading any type of change management effort. And that's what a technology project boils down to -- implementing a change to the way things are today. So how do you manage your change efforts? What should you talk about? And to whom should you talk? My company uses John Kotter's Eight Stages of Change as a framework for structuring the conversation with those involved in projects. Here are some guidelines for getting your conversations started.
Do your homework before you start talking ...
Create Urgency: You may have communicated the purpose of your project, but does it have teeth? Paint a picture of what happens if you don't complete the project. What happens if the status quo remains? And what are the benefits that can be realized when the project is done? Often the improvement is crystal clear to technologists, but murky for others. Especially if the project is something ambiguous to a non-technical business counterpart, such as an infrastructure upgrade or an information security tactic.
Create a Vision: Realized benefits are a great way to frame how your project will make the world a better place (at least the world inside the walls of your organization). Give thought to the bigger picture of your project, so that you can paint the "future state" for your stakeholders. Whether your project will result in internal or external customer facing deliverables, painting a picture -- early and often -- is critical for gaining acceptance.
Form a Guiding Coalition: Formally organizing internal support is extremely important, because it helps sow the seeds of change. We've all heard of steering committees. Well, let's put them to work. First, it's important to get the right people on-board -- those who will help you sow the seeds of change. Ask yourself: How can they help spread the message about the project vision? How can they help contribute to defining the vision, so that it speaks to and resonates with the needs of a particular business area or customer segment? A guiding coalition is important, but the team won't work without a sponsor, leader, or visionary enlisted for the long haul. This is the person continuously driving the vision forward and helping the project team stay the course.
Start Talking ...
Communicate the Vision: Talking about your vision isn't a one-time event done via a mass e-mail. You need a plan that identifies who, when, how, and how often they should hear your message. Look for opportunities to get your vision in front of people -- status meetings, town halls, or messages and alerts in an existing system of upcoming milestones. This is not only an opportunity to communicate, but also an opportunity to sell. And like it or not, your vision is for sale. Your buyers are the people impacted by the changes, and also those individuals whose help you need for the project to be a success.
Get others talking (and doing) ...
Empower Others to Act on the Vision: You may be wondering who is the "you" that I keep referring to in this post. It's anyone and everyone who has a role in contributing to the goals of the project. The guiding coalition helps define the vision and pushes it forward. But in order for the vision to be a reality, others need to get on-board. If people feel boxed in, not supported by management or peers, or lacking access to the necessary tools, your project will fail. Make sure the barriers are removed so others can act on your vision.
Plan for and Create Short Term Wins: This is a great way to start showing progress and proving your theories. It also helps everyone realize that their effort is valuable while keeping momentum going. Think about your project plans in terms of, "how quickly can I get something useful out?" "Useful" doesn't have to mean "perfect"; you can always fine tune later. But showing visible progress sooner, even with a few warts, will provide great insights early-on into what is really important to your stakeholders. This allows your team to correct the course sooner, so be sure to create a formal feedback process to capture stakeholder input.
Don't Declare Victory Too Soon, Sustain the Momentum for Change: We've all experienced it – the anticipation of the much celebrated release party. Celebrating milestones is important, but equally as crucial is being cautious to not signify "it's over". The real work begins when the initial visible change is released outside the project team. That's when things really get started and when it's important to keep up the momentum. Change isn't easy and it's not a static, one-time event.
Institutionalize The New Approaches: We call this "business as usual". If you are implementing something new (technology, process or both), you want it to become the new method of operation. Repetition and reinforcement makes something new feel natural, as if it was the way it had always been. So, you haven't talked enough until you feel like a broken record, and others are repeating your messages and finishing your sentences.
As always, looking forward to any comments and knowledge sharing on the topic!
Do your homework before you start talking ...
Create Urgency: You may have communicated the purpose of your project, but does it have teeth? Paint a picture of what happens if you don't complete the project. What happens if the status quo remains? And what are the benefits that can be realized when the project is done? Often the improvement is crystal clear to technologists, but murky for others. Especially if the project is something ambiguous to a non-technical business counterpart, such as an infrastructure upgrade or an information security tactic.
Create a Vision: Realized benefits are a great way to frame how your project will make the world a better place (at least the world inside the walls of your organization). Give thought to the bigger picture of your project, so that you can paint the "future state" for your stakeholders. Whether your project will result in internal or external customer facing deliverables, painting a picture -- early and often -- is critical for gaining acceptance.
Form a Guiding Coalition: Formally organizing internal support is extremely important, because it helps sow the seeds of change. We've all heard of steering committees. Well, let's put them to work. First, it's important to get the right people on-board -- those who will help you sow the seeds of change. Ask yourself: How can they help spread the message about the project vision? How can they help contribute to defining the vision, so that it speaks to and resonates with the needs of a particular business area or customer segment? A guiding coalition is important, but the team won't work without a sponsor, leader, or visionary enlisted for the long haul. This is the person continuously driving the vision forward and helping the project team stay the course.
Start Talking ...
Communicate the Vision: Talking about your vision isn't a one-time event done via a mass e-mail. You need a plan that identifies who, when, how, and how often they should hear your message. Look for opportunities to get your vision in front of people -- status meetings, town halls, or messages and alerts in an existing system of upcoming milestones. This is not only an opportunity to communicate, but also an opportunity to sell. And like it or not, your vision is for sale. Your buyers are the people impacted by the changes, and also those individuals whose help you need for the project to be a success.
Get others talking (and doing) ...
Empower Others to Act on the Vision: You may be wondering who is the "you" that I keep referring to in this post. It's anyone and everyone who has a role in contributing to the goals of the project. The guiding coalition helps define the vision and pushes it forward. But in order for the vision to be a reality, others need to get on-board. If people feel boxed in, not supported by management or peers, or lacking access to the necessary tools, your project will fail. Make sure the barriers are removed so others can act on your vision.
Plan for and Create Short Term Wins: This is a great way to start showing progress and proving your theories. It also helps everyone realize that their effort is valuable while keeping momentum going. Think about your project plans in terms of, "how quickly can I get something useful out?" "Useful" doesn't have to mean "perfect"; you can always fine tune later. But showing visible progress sooner, even with a few warts, will provide great insights early-on into what is really important to your stakeholders. This allows your team to correct the course sooner, so be sure to create a formal feedback process to capture stakeholder input.
Don't Declare Victory Too Soon, Sustain the Momentum for Change: We've all experienced it – the anticipation of the much celebrated release party. Celebrating milestones is important, but equally as crucial is being cautious to not signify "it's over". The real work begins when the initial visible change is released outside the project team. That's when things really get started and when it's important to keep up the momentum. Change isn't easy and it's not a static, one-time event.
Institutionalize The New Approaches: We call this "business as usual". If you are implementing something new (technology, process or both), you want it to become the new method of operation. Repetition and reinforcement makes something new feel natural, as if it was the way it had always been. So, you haven't talked enough until you feel like a broken record, and others are repeating your messages and finishing your sentences.
As always, looking forward to any comments and knowledge sharing on the topic!
Wednesday, September 2, 2009
RBAC...Why Bother? 4 Reasons to Start an RBAC Program Today
Role Based Access Control (RBAC) is the process of granting people within similar job functions the same access to resources (systems, data etc..) required to do their job. The concept centers on putting into business friendly terms the logical grouping of resource access. These resource access groupings are called "roles". It's a daunting task when you consider all the various systems that can exist within an enterprise - there are the common applications everyone uses like email, the company portal, conference scheduling systems. And the one-offs that are very specific to performing a job function - HR payroll processing apps, CRM tools for Sales personnel, other business specific applications... So why do it? What are the benefits?
Simplification
The process of ensuring that new hires have access to what they need when they need it on day one is not easy. Often it requires several system set up requests before the right access is granted. Not to mention decomposing what someone else in a similar job function has access to. Wouldn't it be easier to have access automatically granted based on the job function someone is in? It's not an "auto-magic" process. There is upfront work involved in establishing the link between job function and system access needs. But once it's done (and the maintenance process is established) the on-boarding of new hires and department transfers becomes a lot easier and quicker.
Action: Get a sense for how much work you are in for. Look at a slice of the enterprise - one job function within one business unit or department. Analyze the system access granted to a few people within the same job function.
Consistency
Even if you know what access is required to do your job the process for getting that access established may vary. You make a phone call to so-and-so to get access to system A, send an email to a mail group to get access to system B, and submit a request through an intranet based system to get access to system C. Sound familiar? With all of these disconnected and differing processes for granting access, how can an organization know that the appropriate scrutiny is being applied to verifying who SHOULD have access to certain applications and information? Is the same approval required for all resource access? In an RBAC environment the role setup process is defined and can evolve as necessary. Based on the specific requirements of an organization the proper controls required for assigning access by job function area established and consistently applied each time that role is requested for a person. Ensuring the right level of approval is applied.
Action: Pick a set of applications and for each ask the question "Who needs to know who is accessing this application?". If the answer results in a Visio diagram, consistency is important.
Accountability
Central to an RBAC model is the governance. Governance takes the form of placing accountability for role definition with those most appropriate to validate what a role should have access to. For roles mapped to job functions that means accountability is placed within the business unit or department where that job function exists. Using business friendly terminology to link a system access permission to a job function is also key. Those accountable for making sure people in that role have what they need to need to understand what the underlying components of a role are.
Action: How easily understood is the system access terminology within your organization? Take one application and create business friendly descriptions to describe the access levels. This will kick start the analysis necessary for establishing a framework to maintain these business friendly descriptions.
Risk Mitigation
If it wasn't apparent already, all the of the above are risk mitigation tactics. The easier and more consistently something can be done, the more predictable the outcome. Predictability helps control risk. An RBAC model reduces the risk that inappropriate access is granted to or retained by someone that shouldn't have it. RBAC is a key control in information protection.
What benefits has your organization seen from an RBAC? implementation?
Friday, August 21, 2009
How Mature Is Your Identity Management Program?
Identity Management maturity can be defined by 4 levels that include aspects of people, process, and technology. Because of this, moving along the continuum requires the commitment of senior leadership to support the organizational changes required. The following presentation summarizes the framework for determining maturity and provides suggestions for advancing between levels.
Identity Managment Maturity Model
View more presentations from kmanthey.
Thursday, August 20, 2009
Stop Wasting Money Writing System Requirements
IT has long been looked to as the technical solution providers for business problems. But the assumption that often is made is that the business problem is already well understood and the business processes that drive the technical requirements are known....by someone. I continually run into the situation where a team is beginning the business requirements definition effort and developing system Use Cases only to discover it's not that straightforward. The entire business process that the technology will support has not been thought through and there are gaps in knowledge around some areas of the business process. How can this be addressed before valuable time and money are wasted spinning on requirements? Here are a few suggestions:
Every IT project should start with business process definition. It's no longer IT's responsibility to only handle the system requirements definition side of the equation. Start thinking in terms of process steps, roles, and responsibilities. Once these are defined the role of the system and how it should behave becomes more clear. The same skill set that it takes to identify system requirements is highly transferable to defining business process. Stakeholder engagement, meeting facilitation, communication skills, clear concise documentation abilities are all the qualities of solid business AND process analyst.
Run an agile project. By adopting the basic principles and philosophy of the agile scrum framework your team can get to "doing" faster with "just enough" documentation in place to make it productive. Once the business process is well understood, create a backlog with the goals the system should allow each type of system user to achieve. Define requirements in more detail as part of each development sprint. Start the sprint with a few upfront requirements tasks then continue to refine the requirements as a team through the build-demo-adapt process. The role of the BA in the demo meetings is to capture requirements and decisions made. By the end of each sprint you can have a requirements document that matches exactly what was built. This avoids spending months in lengthy requirements gathering sessions trying to predict in excruciating detail today how you want the system to work a few months from now.
These are a few ideas that have worked well on my projects. Join the conversation! What are you doing that's worked well(or not so well)?
Every IT project should start with business process definition. It's no longer IT's responsibility to only handle the system requirements definition side of the equation. Start thinking in terms of process steps, roles, and responsibilities. Once these are defined the role of the system and how it should behave becomes more clear. The same skill set that it takes to identify system requirements is highly transferable to defining business process. Stakeholder engagement, meeting facilitation, communication skills, clear concise documentation abilities are all the qualities of solid business AND process analyst.
Run an agile project. By adopting the basic principles and philosophy of the agile scrum framework your team can get to "doing" faster with "just enough" documentation in place to make it productive. Once the business process is well understood, create a backlog with the goals the system should allow each type of system user to achieve. Define requirements in more detail as part of each development sprint. Start the sprint with a few upfront requirements tasks then continue to refine the requirements as a team through the build-demo-adapt process. The role of the BA in the demo meetings is to capture requirements and decisions made. By the end of each sprint you can have a requirements document that matches exactly what was built. This avoids spending months in lengthy requirements gathering sessions trying to predict in excruciating detail today how you want the system to work a few months from now.
These are a few ideas that have worked well on my projects. Join the conversation! What are you doing that's worked well(or not so well)?
Wednesday, August 12, 2009
SaaS - Making the Right Choice for Your Company
Software as a Service (SaaS) is gaining more ground as a viable option for addressing IT needs in all sizes of companies. No longer looked at by only SMBs as the low cost alternative to expensive custom software solutions. Before you jump into a SaaS solution, it's important to do your homework, both on the SaaS provider and within your own company. Here are a few things to consider:
Know what SaaS is (and is not)
In basic terms, SaaS is subscription based software accessible over a network (i.e. the Internet). The SaaS vendor assumes maintenance responsible for all hardware and software components. The obvious benefit is that a company or subscriber gets the functionality they need without the IT overhead associated with an in-house application - hardware costs and maintenance, software support. The downside is that the customer does loose some control. As a customer you may be limited to the customization options available within the base software solution. You also need to be aware about how your data is stored and how accessible it is to you.
The SaaS Vendor's Maturity
In a recent Forrester research report, SaaS vendor maturity can be defined as:
How flexible are they? Do you know what your must-haves are? The benefits of many SaaS options can also be a drawback if you haven't taken the time figure out what you are really looking for. There are often limited customization abilities and some of your business processes may require specialized features/functionality. Make sure your business process is well defined and understoond before looking at vendors. Regardless of how flexible your business process is there are always a few requirements that must be met.
Vendor Evaluation Criteria:
Give careful thought to the specifics you will rate a SaaS vendor against. Categories that should be part of any SaaS vendor evaluation include (but are not limited to):
I'd love to add to this list of SaaS vendor considerations. What was helpful in your SaaS vendor evaluation?
Know what SaaS is (and is not)
In basic terms, SaaS is subscription based software accessible over a network (i.e. the Internet). The SaaS vendor assumes maintenance responsible for all hardware and software components. The obvious benefit is that a company or subscriber gets the functionality they need without the IT overhead associated with an in-house application - hardware costs and maintenance, software support. The downside is that the customer does loose some control. As a customer you may be limited to the customization options available within the base software solution. You also need to be aware about how your data is stored and how accessible it is to you.
The SaaS Vendor's Maturity
In a recent Forrester research report, SaaS vendor maturity can be defined as:
- Level 0: Outsourcing is not SaaS. In outsourcing, a service provider operates a major application or a unique application landscape for a large enterprise customer. As the outsourcing company can't leverage this application for a second customer, outsourcing does not qualify as SaaS.
- Level 1: Manual ASP business models target midsize companies. At level 1, a hosting provider runs packaged applications like SAP's ERP 6.0, which require significant IT skills, for multiple midsize enterprises. Usually, each client has a dedicated server running its instance of the application and is able to customize the installation in the same way as self-hosted applications.
- Level 2: Industrial ASPs cut the operating costs of packaged applications to a minimum. At level 2, an ASP uses sophisticated IT management software to provide identical software packages with customer-specific configurations to many SMB customers. However, the software package is still the same software that was originally created for self-hosted deployment.
- Level 3: Single-app SaaS is an alternative to traditional packaged applications. At level 3, software vendors create new generations of business applications that have SaaS capabilities built in. Web-based user interface (UI) concepts and the ability to serve a huge number of tenants with one, scaleable infrastructure are typical characteristics. Customization is restricted to configuration. Single-app SaaS adoption thus focuses on SMBs. Salesforce.com's CRM application initially entered the market at this level.
- Level 4: Business-domain SaaS provides all the applications for an entire business domain. At level 4, an advanced SaaS vendor provides not only a well-defined business application but also a platform for additional business logic. This complements the original single application of the previous level with third-party packaged SaaS solutions and even custom extensions. The model even satisfies the requirements of large enterprises, which can migrate a complete business domain like "customer care" toward SaaS.
- Level 5: Dynamic Business Apps-as-a-service is the visionary target. Forrester's Dynamic Business Application imperative embraces a new paradigm of application development: "design for people, build for change." At level 5, advanced SaaS vendors coming from level 4 will provide a comprehensive application and integration platform on demand, which they will prepopulate with business applications or business services. They can compose tenant-specific and even user-specific business applications on various levels. The resulting process agility will attract everyone, including large enterprise customers.
How flexible are they? Do you know what your must-haves are? The benefits of many SaaS options can also be a drawback if you haven't taken the time figure out what you are really looking for. There are often limited customization abilities and some of your business processes may require specialized features/functionality. Make sure your business process is well defined and understoond before looking at vendors. Regardless of how flexible your business process is there are always a few requirements that must be met.
Vendor Evaluation Criteria:
Give careful thought to the specifics you will rate a SaaS vendor against. Categories that should be part of any SaaS vendor evaluation include (but are not limited to):
- Price
- Alignment with functional requirements and business process requirements
- Useability
- Technical Requirements such as
–Security
–Data Storage and Accessibility
–Disaster Recovery
–Custom Reporting
–Integration
–Customization - Support SLAs
- Professional Services
- Vendor Viability
- Regulatory Compliance
I'd love to add to this list of SaaS vendor considerations. What was helpful in your SaaS vendor evaluation?
Tuesday, July 14, 2009
Subscribe to:
Posts (Atom)