As your company has grown, do you find yourself having a harder time connecting with your employees? As our number of employees, clients, and worksites has increased, so has our need to find new and innovative ways to collaborate. At IBC, 65% of our Executive Leadership is not in the office on a normal workday. When you factor in our full extended management team that also work offsite on a daily basis, that number increases to 90%. One can only imagine how difficult it must be to hold basic status, planning, and strategy meetings while achieving a high active participation level. As we have begun to mature, new ways to drive collaboration have developed:
- Be Flexible With Expectations
These days it is unrealistic to have all employees working in one location on a strict ‘9 to 5’ schedule. When you factor in additional client obligations, finding times for groups of employees to meet can be extremely difficult. Flexibility is key to overcoming this challenge. For example, instead of always having your meetings at the same location, try rotating locations closer to large employee clusters to make things easier for those coming from client site. This past week, in an effort to increase attendance, IBC held a company All-Hands Meeting away from our normal meeting location, but closer to where a number of employees are located; it worked! It was our most widely attending all-hands meeting in the past two years. Accept the reality that in today’s dynamic work environment, you will not always be able to meet face-to-face. In addition to this, there are tools that have proven to be more effective in collaboration than the old “tried and true” techniques of ten years ago. Online collaboration tools and techniques can and should be used to your advantage!
- Use What Works For Your Company
It is safe to say that the days of only collaborating remotely through phone and email communications are long gone. Growing companies need to be able to strategize, respond, and react in real-time, no matter where their employees are located. Play to your employees strengths. “You’ll get the greatest payoff from online collaboration if you make use of an eclectic range of collaboration tools that support a diversity of working and communication styles,” wrote Alexandra Samuel in Harvard Business Review. At IBC, we use Evernote to share notes and ideas, allowing our employees to build off of each other’s thoughts that come out of brainstorming sessions and comment virtually. For internal communications, we leverage Yammer when broadcasting information quickly and in real time, to ensure that no one is left out of the loop. This also allows us to host this information in a searchable format rather than in someone’s overloaded inbox so it can quickly be found. And while we do still use traditional conference calls on a daily basis, when appropriate we turn on the webcam for a more personable videoconference call. These methods work for us, but that doesn’t mean they will always work for us, so we are constantly looking forward to the next idea. But, as Microsoft states in their Whitepaper Accelerating Team Collaboration with Social, “the key is to use the right set of social technologies that support open communication and seamless collaboration”. Find what tools work for your employees and allow your company to be flexible in those tools to continue effective communication amongst your staff.
Collaborating becomes harder and harder the larger and more widespread your company is. As an emerging business, you need to be flexible to accommodate those within your organization, and utilize the tools and techniques that work to help facilitate collaboration. IBC understands that adapting to the changing environment is key, both for our organization and our employees, and by doing so, our collaborative efforts have never been stronger.
These are some of our techniques on #HowToCompete using new forms of collaboration, what are yours?
Join the #HowToCompete discussion:
[statictweets skin=”simplistic” resource=”search” user=”” list=”” query=”#HowToCompete” count=”5″ retweets=”on” replies=”on” show=”username,screenname,avatar,time,actions,media”/]
How does your company identify opportunities to pursue? Dozens of solicitations are identified each week by our staff, but how do we decide which ones get sent to the recycling bin and which ones remain? As your company has grown, have you found your process has changed? Are you finding that opportunities that your Small Business would have been a shoe-in to win, are now long-shots for your Large Business? We at IBC deal with these issues on a seemingly daily basis.
Given these issues, what can we do to increase our capture win-rate? Here are a couple areas that we are currently focusing on:
Leverage Your Company’s Competitive Advantage
Bill Carmody, CEO of Trepoint, says “by getting in touch with what makes [your company] unique and special, you can unleash your superpower and with it a virtually unlimited amount of untapped opportunity.” In this case, your company’s superpower is your company’s competitive advantage and this shouldn’t change due to your company size. Although IBC may no longer be a “specialized” small business, focusing solely on a small number of solution areas, our main strengths remain. We still employ experienced Agile and Scrum experts. We still are one of the leading firms in providing SAP solutions to the Federal Government. These are two of IBC’s strengths, regardless of what our size is. The fact that our company has grown does not mean we should immediately start jumping into untouched waters, or focusing on areas where our stories are less compelling. Kevin Daum writes “a great opportunity can provide me growth, but it should not require me to change who I am at the core.” Just because you are no longer a small business, don’t forget what enabled you to grow that small business into what it is today.
Create Solicitation Response Criteria and Stick to it
Does your company have specific solicitation criteria that must be met before you respond to a request? And if so, does your company make exceptions when RFPs are released that, while not meeting your set criteria, just seem like they would be a good fit for your company? If you are guilty of doing this from time-to-time (and we know we are), you are either spending time, hours, and money on a bid that likely has a lower win probability than other opportunities out there, or you need to rethink your criteria.
Don’t only judge a request based on the solution you know you can provide. Put yourself in the customer’s shoes and think about what they are looking for when they read through the deluge of responses that are sure to come in. At IBC, we look at the following criteria when deciding to bid or not:
- Do we know the customer?
- Do we have past performance to support our story?
- Do we have the expertise to support our story?
- Can we price to win and live with those financial impacts?
Consistently identifying winning opportunities is difficult, but that by no means has deterred us from trying to increase our win-rate. By focusing on our competitive advantage and strengths, and sticking to our RFP response criteria, we at IBC hope to be able to do just that.
These are some of our strategies on #HowToCompete through Opportunity Identification, what are yours?
Join the #HowToCompete discussion:
[statictweets skin=”simplistic” resource=”search” user=”” list=”” query=”#HowToCompete” count=”5″ retweets=”on” replies=”on” show=”username,screenname,avatar,time,actions,media”/]
As part of your company’s growth planning, have you ever thought about what it means to no longer be small? Within the Federal and DoD arenas, graduating from small business, no matter what your company’s demographic, can be strategically challenging and growth limiting if you have not developed a well thought out small business exit strategy and plan.
IBC, a DBS company faces this very challenge: fully integrating two small businesses in October 2013; streamlining two organizations operations in 2014; graduating from small business in early 2015. As an organization, we continue to analyze, assess, and focus our growth strategy each month as we decide what markets to continue to support, and what markets to target as we grow.
Over the coming weeks, we will be starting a series of discussions for other small and emerging businesses to consider. We will focus on areas such as: Business Development and Capture Planning; Operations Efficiencies: Business and Software Partnering Objectives; Social Networking and Marketing; Staff Alignment; Market Focuses. Each week we will be analyzing various articles, providing our thoughts and insight, and opening the lines of communication to all those interested. We encourage you to participate in each topic discussion by using the hashtag #HowToCompete on Social Media.
We recognize that we do not have all the right answers, so believe that in facilitating this discussion, we will help other emerging small businesses and ourselves as we continuously refine our growth strategy in 2015 and beyond.
Join the #HowToCompete discussion:
[statictweets skin=”simplistic” resource=”search” user=”” list=”” query=”#HowToCompete” count=”5″ retweets=”on” replies=”on” show=”username,screenname,avatar,time,actions,media”/]
Let’s face it. If you work in the SAP world and haven’t heard about HANA, you’re living under a rock (or maybe still on R2?). In the past three years, every SAPPHIRE, ASUG and TechEd (sorry, d-Code) event has focused primarily on HANA and its benefits. SAP is now even rewriting and pushing down their ABAP code to HANA to take advantage of its capabilities. S4HANA and Simple Finance have the capability of drastically simplifying an organizations data models. However, a number of customers have purchased HANA as their BI solution, but are not quite ready to take the leap to these solutions. That’s where the HANA Accelerators come in. The HANA Accelerators (aka, HANA Side Car) allows customers to leverage their HANA investment like never before. By redirecting the selects from their standard database to HANA, significant performance improvements can be gained with this technology. And the beauty of this solution is that the implementation time is very fast, saving you money and improving your ROI.
If you are like most of my customers, your system performance was probably great when you first went live – especially if you did a phased rollout. However, as time has passed, you’ve likely added additional organizations, new processes and more data to the system. While the old saying ‘Disk is cheap’ may be true, getting to the data on the disk becomes more expensive the larger the dataset. At least, that’s the way it’s been with traditional databases. With the introduction of HANA, SAP has revolutionized the way that data is stored and accessed. Through the use of the column store database, the data within the database is compressed significantly – in most cases by a factor of 7 or more (by that I mean, 7 terabytes of row store data becomes 1 terabyte of column store data). Once the data is compressed, the amount of RAM needed to put the data into memory is much less. Accessing data in RAM is an incredibly more efficient method than having to access it via disk – even with Solid State Drives. But to me, this isn’t even the greatest benefit – at least not from a business perspective. Since the data is stored in columns, every column essentially becomes an index. This has two incredible benefits. First, there is no need to have secondary indexes on your tables. This alone can save a huge amount of disk space. Second, it means I can now access my data using any combination of fields I want. From an end user perspective, this is huge. I am no longer limited to the indexes someone else chose for me. And what that really means is that not only can I analyze my data in ways which meet my exact business needs, but I can even design the system in ways that were never possible.
While Suite on HANA is starting to gain traction, many customers would like to see a better return from their HANA investment today. In order to do this, SAP has delivered two Accelerator products. The most commonly known product is the ERP Accelerators. The ERP Accelerators are a collection of specific points in SAP’s standard code, whereby a redirect to HANA is performed. The ERP Accelerators were delivered as part of the standard system with SAP Note 1620213 (and subsequent additional notes). Below is a list of just a few of the delivered accelerators.Table 1 – SAP Delivered ERP Accelerators
In addition to these, there are a number of other accelerators and SAP continues to add to this list. The accelerators can be categorized into one of the three areas:
- Reporting – These accelerators are used to select data quickly from the standard line item tables like BSEG, GLFLEXA, PSMGLFLEXA, ANEP, COEP, etc.
- Transactional – These accelerators are used within the processing of transactions like posting an FI document or running CO Allocations
- Interface – These are primarily BW related where a Virtual Infoprovider can be setup from BW
The second Accelerator product is the Business Application Accelerators. This product allows you to redirect any of your own custom programs. The product is an add-on to the standard system and must be requested via information in SAP Note 1694697.
One additional transaction of note is the General Table Display. If you’ve been using SAP long enough, you’ve probably used transaction SE16. SAP has delivered a new transaction – SE16H. This new transaction allows you to select your secondary database connection and query data directly within the ERP system. Additionally, this transaction allows you to do a left outer join with another table from your standard database or from HANA.
While most customers are unaware, SAP has provided the ability to connect to a secondary database from within the ERP system since the days of R/3 4.0B. The transaction DBCO allows user to create a connection to another database by providing the IP address of the database server and login credentials. The HANA Accelerators utilize this secondary connection to redirect the selection of data from the standard installed database to HANA.Figure 1 – DBCO Secondary Connection
Of course, the data first needs to reside in HANA in order to utilize this redirection. This is where the System Landscape Transformation (SLT) product is essential. By using the SLT, data can be replicated from the ERP system in near real time. This provides for the use of the functionality with not only reports, but with transaction processing. The SLT is a product that creates triggers at the database level which are executed anytime an Insert, Update or Delete occurs on a specified table. The trigger then populates a shadow table with the key of the table to keep a record of which entries need to be transferred. The SLT system then copies the record from the ERP system to HANA using RFC connections. This entire process usually takes less than a second to go from the update in ECC to the update in HANA. SLT does allow for more advanced ETL capabilities, but this is the basic concept. One thing to note – in order to use the accelerators for a specific table, the structure of the table must be the same in both systems. I’ll even take this one step further – I believe the data should be a mirror of each other (e.g. no transformations). My reasoning here is simple – If I run a report that is not accelerated and compare it against one that is, there should be no difference in the results.
Once the basic setup is complete for connecting and replicating to HANA, it’s time to view each accelerator. In transaction HDBC (or HDBS), you can view each accelerator to determine the functionality and requirements to activate. Each accelerator can be activated across your whole system or by user id. Further, the accelerator can be activated and deactivated very quickly in case you run into issues.Figure 2 – ERP Accelerator – General Settings
The key to being able to activate an accelerator is the existence of the necessary tables in HANA with the structures identical. Some accelerators have as few as one table required, while others have a large number. In figure 3 below, the General Ledger Line Item Browser with its new transaction FBL3H requires five tables from the ERP system as well as a new generated view that can be created from this screen. The generated views are created in the ERP system as well as the HANA system – both without data.Figure 3 – ERP Accelerator – Replication Tables
Business Application Accelerators
The BAA is an add-on product that must be applied via transaction SAINT. The component name is SWT2DB. To use this product, an XML file is created which defines the program and table which will be redirected. Once the XML is uploaded, a database connection (from transaction DBCO or DBACOCKPIT) is assigned to the scenario. The scenario is then activated and all future selects are redirected.
In our experience, the BAA is just as important (if not more so) than the ERP accelerators. With this component, we have enabled numerous reports and interfaces to run significantly faster than before. Let’s face it – SAP developers do a pretty good job of writing efficient code, while other developers do not have the quality assurance and performance mindset of those in Waldorf or Palo Alto. At most of my clients, the long running programs are typically the ones that start with a Z. As such, some of the largest gains we’ve seen is through the acceleration of reports, extracts and interfaces via the BAA.
Now if you’ve made it this far, you must be wondering about the results. These products have truly transformed some of my client’s experiences. The end users no longer have to wait minutes and hours for reports, the O&M team does not have to stay up all night monitoring jobs, the database administrators are happy that the primary database is not dragging, and the functional team is free to organize the data any way they want. Some specific examples of what we’ve seen are:
- One interface was running for over 15 hours. After acceleration via the BAA, it ran for 9 minutes.
- The Cost Allocation program was running for over 24 hours at the end of the month – it now runs in 20 minutes.
- The Vendor Line Item Browser would timeout and never return the data for some vendors – now it runs in less than 1 minute.
- Depending on how some users ran reports, the system would either timeout (if in foreground) or run for days (in background). Now the users can select their data however they want and the data is returned in seconds.
The additional speed is nice, but it really comes down to what happens when you attain this level of performance. If a report takes 5 minutes to return the data, the user will hopefully do some other work – but they may just take a short break. If it takes 3 hours, they’ll definitely do other things, but they’ll also rarely rerun that report based on their findings. If the report returns the data in 30 seconds, the user can do something actionable with that information (like post a correcting entry, etc.) and rerun the report to analyze the data again. Providing a system that works for your users, improves their performance, improves the overall system performance and ensures increased satisfaction and acceptance of the system are all possible with the HANA Accelerators.
To learn more about how to make the Side Car your Main Car, contact us at www.ibcdbs.com/contact/.
Over the past decade, the majority of organizations have made investments in SharePoint, either as a content management or business collaboration platform. This trend has continued with Microsoft’s latest release, SharePoint 2013, and the steady growth in Office 365 subscriptions. The continued popularity of the SharePoint platform is somewhat perplexing, given the rate at which SharePoint implementations fail to meet user expectations.
SharePoint appears simple from the outside, and to be fair, it is pretty easy to get up and running out-of-the-box. It is in this simplicity, however, where the danger lies, ready to ruin great ideas. Given the relatively low up-front cost and effort, organizations frequently underestimate the complexity and effort it requires to deliver a successful SharePoint solution. In fact, according to a recent AIIM survey[i], only 6% of respondents consider their SharePoint projects successful, while 61% have either failed, stalled or are struggling. The most common barriers to success mentioned were lack of expertise, lack of vision, poor user adoption, and lack of governance.
If you’re reading this thinking “wow, that sounds familiar”, you’re not alone. The first step in revitalizing your SharePoint project, or avoiding these common missteps in a new implementation that you’re planning, is getting a better understanding of what went wrong and why. While there is no single secret to turning around your project, we strongly believe that asking a few key questions around the most common barriers is a good way to start addressing these challenges.
What is your organization’s vision for SharePoint?
39% of respondents claimed their SharePoint projects were not succeeding due to lack of vision and strategy. ii
SharePoint can be just about anything you want it to be, but defining what it should be is the challenge. Often times organizations will implement SharePoint and assume all of their content management and collaboration issues will magically disappear. When organizations mix and match terms such as “Portal” and “Intranet” with SharePoint, it’s likely that the solution is being considered in too broad a context. The truth is that SharePoint by itself isn’t the answer many are looking for. SharePoint is the platform to build out solutions to address those issues, but understanding needs up front and having a plan to address them is critical. Define your high priority projects, build out a roadmap for their implementation, and spend the time to define how your vision for SharePoint aligns with the objectives of these projects. Rolling out SharePoint alone won’t do you any good if it fails to add value to your organization, so before you go and start a SharePoint project, make sure you have a vision for it.
Ensure you have a strong sponsor
The success of any SharePoint project is highly dependent on a strong sponsor. Before investing time and money into a SharePoint project, ensure you have a project sponsor that is willing to work with your team to set priorities and drive user adoption from the top down. Even better, encourage your sponsor to lead by example, and users will follow.
Let people drive your strategy, not technology
New technologies come into the marketplace all the time. The latest and greatest bring a variety of new features that tend to entice those that are more technologically savvy. When developing your SharePoint vision, make sure that the needs of the business and your users are at the forefront, not the features in the latest release. If something in place already works, it may be good enough. If not, ensure you involve key business stakeholders in the evaluation process.
Start small, build momentum
Provided the opportunity, identifying “low hanging fruit” to get a quick win is never a bad idea. It allows users to become comfortable with SharePoint and helps build confidence in the tool while making their job easier. If you’re successful, users will identify other opportunities to add to your SharePoint backlog. As your backlog grows, be sure to prioritize according to business needs as well as your ability to deliver. Consistently delivering focused solutions that meet the needs of your users help maintain your momentum and drive user adoption.
Do you have skills to be successful?
46% of respondents claimed their SharePoint projects were not succeeding due to lack of SharePoint expertise.[ii]
SharePoint is not a document management tool. SharePoint is not a collaboration portal. SharePoint is a platform. The SharePoint platform is a great basis to develop a solution for your organization’s specific needs, but it must be developed. There are numerous features available, and with so many features comes complexity. IT generalists and administrators cannot, and should not, be expected to know the intricacies of SharePoint. While they may be sufficient for environment maintenance, designing a content management strategy, information architecture and taxonomy optimized for SharePoint, should be left to SharePoint architects. SharePoint developers should be involved when customizations are required to ensure a positive user experience, adherence to best practices and long term sustainability. There’s no substitute for the experience SharePoint architects and developers bring when implementing a solution to meet a critical business need. If you lack SharePoint specific resource in-house, take one of the following measures to help your project succeed.
Outsource to specialists
The easiest and quickest answer to obtaining SharePoint expertise is to procure the services of SharePoint consultant. SharePoint consultants come in a variety of flavors. Some are generalists, while others are extremely specialized with a deep knowledge of a given feature set. The best SharePoint consultants aren’t necessarily cheap, but they provide innovative solutions and get the most out of the platform before opting for custom solutions. They are experienced, and are able to draw on those past experiences to guide you to success.
Hire an expert
If outsourcing isn’t an option, consider hiring experienced SharePoint resources for your current and future SharePoint projects. This may not be the ideal solution for short-term needs, but if your organization is large enough, and you plan on continuing your investing in SharePoint, this could be a viable option.
Invest in SharePoint training for motivated staff
SharePoint training is readily available from many providers if you prefer to train your current staff. IT staff are obvious candidates for SharePoint administrative training, but many engaged business analysts make great SharePoint ‘power users’ as they already understand the business process, and can then apply SharePoint out-of-the-box features to complement the process. This option is not ideal for immediate needs, and there is no substitute for experience, but a possibility for non-critical projects and supplementing longer-term efforts.
What is your governance plan?
19% of respondents claimed their SharePoint projects were not succeeding due to lack of governance. ii
Governance is a must around any SharePoint project. Without a good governance plan in place, your SharePoint solution will likely revert back to file share with slightly better search capabilities. It will also be susceptible to “SharePoint Sprawl”, a term used to describe the speed at which SharePoint implementations can quickly get out of control by users creating unneeded sites and storing content in disparate locations with no way to efficiently locate and retrieve when needed. Once the sprawl starts, it is difficult to stop, so here are a few ways to start getting your hands around it.
Reevaluate your information architecture
Information architecture is critical to any SharePoint project, and hopefully was done as part of your governance planning. If so, great, now is a good time to evaluate how effective it is and how it’s being enforced. If not, its time to take a look at how your users have been using SharePoint thus far, and then meet with your users to understand how they’d like to use it in the future. Based on their feedback, rethink your solution, create new content types, and consolidate duplicate sites, libraries, and lists. The sooner you align your information architecture with the needs of your users, the better.
Inventory and monitor sites
Poor governance often leads to dormant sites. Users create sites when they really need a library or create sites in the wrong place accidentally. The number of sites in many organizations we’ve seen has been staggering. Understanding how these sites are being used is a must before starting the clean up effort. Fortunately, it’s pretty easy to see how often sites are being accessed and how stale content is within a site. Unfortunately, knowing if that content is also duplicated somewhere else is not. Moving forward, limit who can create sites, develop usage reports, identify underused sites, and remove or consolidate as needed.
Utilize SharePoint’s document routing features
SharePoint has features that allow you to create rules that will move documents to a particular site or library based on the document’s characteristics. Enabling these features simplifies the process for users and improves compliance with the organization’s information policies. Simplifying any process for users is rarely a bad thing.
What tools are people using to get work done?
27% of respondents claimed their SharePoint projects were not succeeding due to poor user adoption. ii
If users are not using SharePoint, odds are, they sought out, and found alternatives to the existing solution. If the intent was for document management, most likely they’re using email or consumer grade tools like Dropbox, Google Drive, or Box. If you designed a fancy workflow solution, your users may have found it more complicated than sending an email or picking up the phone. Regardless of what it is, they have found an easier way, and you may have to go back to the drawing board to make them comfortable with your SharePoint project.
Engage users in the process
It is critical to understand your users and how they work before designing any SharePoint solution. Users need to feel a sense of ownership and that you are designing a system to help them do their work, not force them to change in how they work. Throughout the planning and design process, meet with a variety of users across the organization regularly to collect feedback, discuss ideas and review prototypes. Engage users early and often for improved user adoption.
Ensure users are properly trained
Deploying a solution without proper training will confuse users and give the impression that your solution is complicated. Take the time prior to the rollout to plan multiple sessions for each user roll. Develop help guide materials and FAQs and make them readily available, ideally, accessible from within the solution itself. During rollout, have extra support available to answer any questions that may arise, but don’t wait for users to ask. Wander the halls and check in with them to get initial feedback. The earlier you can identify any potential issues, the faster you can fix it, and the fewer users will be impacted.
Monitor and evolve
Once you deploy your solution, it’s only the beginning. As part of your vision and strategy, you should have set some sort of goals. In order to measure your success, you need to monitor usage and any other applicable statistics. Actively monitoring and analyzing usage metrics allow you to identify features users like and others that may need to be reevaluated. With each iteration or additional feature added, you will have a better understanding of what is successful, and be able to improve user adoption.
All SharePoint projects can be successful provided the proper planning is completed from the outset, to establish a SharePoint vision and governance model that makes sense for the organization. SharePoint experience and expertise is critical to designing and delivering solutions that users will embrace while making them more productive. However, hindsight is 20/20, and when projects fail, starting over may not a viable option. If this has happened at your organization, all is not lost. Consider enlisting the help of a third party to assess your SharePoint program. They will be able to assist you in developing a focused vision and governance plan that is appropriate for your organization. Once the vision has been established, they will be able to provide you a SharePoint Roadmap, steering you clear of common barriers and guiding you to success.
Do you need help revitalizing your SharePoint project, or planning a new one? At IBC, we understand the vast array of issues and challenges organizations face when implementing SharePoint. When you engage IBC as your SharePoint partner you gain access to a team of SharePoint experts that includes SharePoint Architects, SharePoint Developers, SharePoint Mentors, and SharePoint Support and Maintenance Specialists. Our SharePoint services team using best practices, ensures that your SharePoint solution meets your company’s needs while allowing your IT resources to remain focused on your company’s core business.
I used to be part of the “non-believers” when it comes to agile software development. I’ve since converted to an agile evangelist of sorts, and appreciate the significant benefits the agile approach has to offer. While my own conversion was not so easy, I’ll explain the transformation, what I consider to be the key program management benefits associated with the agile approach, and a few challenges that I think still remain.
Why the change to agile?
Having just completed a very lengthy and stressful, yet highly successful waterfall development project, I turned my nose at the thought of moving to the agile approach. Why not just capitalize on everything we learned and kick-off the next project initiation phase? Truthfully, I was anxious to get started on the next release, and time spent changing our life cycle methodology was only going to delay our start. Plus, I didn’t see how we would deliver the end product any sooner. The methodology was being thrust upon us from an oversight organization, essentially calling it the “panacea” for our lengthy, high risk, waterfall development approach.
My Initial Skepticism
With the decision to move to agile essentially made for me, I attended the Scrum Master Certification class and passed the certification exam. Taking the class certainly didn’t convert me into a believer. In fact, I was even more skeptical after reviewing the “agile manifesto”:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
As a practicing Project Management Professional (PMP), one thing became very clear to me – the agile manifesto had to be written by a group of software developers! My experience showed that software developers (1) hate to plan, (2) hate giving me status reports even more, (3) hate documentation, (4) hate process, and (5) steer as far away from a contract as possible. Surely, only a group of software developers would come up with this methodology that allows change to happen repeatedly and documentation to take a back seat to working software. I left the Certified Scrum Master (CSM) certification class feeling like the agile manifesto was a publicity stunt crafted by developers to let them focus solely on writing software. Hmm…. can’t wait to see this actually in process.
The Transformation Begins
Looking back, I suppose the things that started making me a believer were directly related to the things I dislike about the waterfall development approach. The agile development approach solves many of these key items:
- Trying to plan and estimate how things will go during the latter stages of development and testing while you are in the project initiation phase is almost a complete waste of time, no matter how many times you’ve delivered projects of the same scope and size. The Project Management Body of Knowledge teaches us that every project is unique. Trying to estimate future development activities before the design phase is complete will always lead to inaccurate results no matter how many times you’ve done it before. The agile development approach allows you to plan in reasonable “chunks” called sprints or iterations or increments. This activity is much more reasonable, and incredibly more accurate. Additionally, once you’ve done it successfully a few times and your stakeholders buy-in, you can use your own team velocity as a predictive measure.
- Having daily, in-person interactions with the team is extremely compelling. One of the things I hated during the waterfall cycle was requesting weekly status from developers to update my integrated master schedule. This hatred was exacerbated when we became “behind schedule” and significant re-planning was necessary to get us back on track and remain “within baseline”. No amount of time spent re-planning ever allowed us to make up schedule variance. Scheduling is one area where looking at comparative project data was accurate – software development projects that are behind schedule rarely, if ever, get delivered on time. Listening to developers give status each day, in person, benefits the entire team by avoiding multiple interpretations of a status report and confirms the entire team is on the same page.
- Communicating status to your peers every day can be motivating. Using the agile approach, team members are required to articulate what they did yesterday, what they plan to do today, and any impediments they have to completing assigned tasks. This ceremony – “ the daily stand-up” is the center of the workday for the team. During a long, 6-month waterfall development cycle, slipping a week or two seems harmless (even though as noted above, we know it never gets made up). In a typical agile two or four-week sprint, not completing your assigned tasks can be scary. Who wants to admit to their peers on a daily basis they can’t get the job done? Whether the challenge is related to a technical issue or a functional issue, any barriers to success (called “impediments”) are highlighted and addressed daily. This increased accountability to your teammates drives increased productivity.
- Frequent feedback from an end user representative is even more compelling. User acceptance testing happens at the end of the traditional waterfall life cycle. I recall the overwhelming stress associated with demonstrating an “end-product” all at once. Of course this final acceptance led to significant changes at a very costly time – when development was complete. Getting feedback from a fully empowered product owner during the course of a 2 or 4-week sprint, and an expanded set of stakeholders at the end of the sprint almost eliminates the acceptance testing risk. The frequent and early feedback cycle allows the development team to make corrections as part of the normal sprint process – much more effectively than at the end the waterfall cycle.
- Designing as you go is more successful than overhead-intensive quality gates. Producing, reviewing, inspecting, and finalizing dozens of deliverables to pass a waterfall quality gate increases project stress. Largely a paperwork drill, preliminary and critical design reviews for example allow a team to create a baseline design, which is sure to change once full-scale development is finally underway. Building accurate requirements, design, and testing artifacts as you progress through the agile development life cycle is much more successful, and whole lot more logical.
The Agile PMO Manifesto
All of these benefits associated with moving towards an agile development methodology not only convinced me it was a much better approach, but also showed the agile methodology creates a much more enjoyable environment for all parties. This better environment can be summarized in the “Agile PMO Manifesto” –
Two Week Sprint Plans over 1000+ line integrated master schedules
Daily lightweight status updates over monthly status reports and variance analysis
Daily risk and issue management over risk control boards and endless risk analysis
Frequent cycles of user acceptance and design reviews over infrequent quality gates
This agile PMO manifesto suits a PM much better. Even the most hardcore, “by-the-book”, PMP would have a hard time disagreeing with these principles. If the agile manifesto has been supplemented with these items, I would have been a believer in the agile development approach since day one.
Still not a Panacea, but a Great Start
Moving to an agile approach does not solve all software development problems. Indeed, program sponsors will always want answers to two key questions: (1) “When will you be done?” and (2) “How much is this going to cost?” Agile development actually makes the answers to these questions challenging. At IBC, our collective experience with agile projects has shown us the “triple constraint” of weighing scope, schedule, and resource variables against one another is very much still a requirement. Agile development is considered a “capacity-driven” approach, meaning the agile team can accomplish whatever the agile team can accomplish. Until the “velocity” or throughput of an agile team is determined, the end date of a project, and the associated budget, remain largely estimates. This scenario makes it difficult for a sponsor to fund a project if the velocity, and answers to the two key questions, will not be known for a few sprint cycles. We’ve identified this challenge in multiple client scenarios, and came to the realization that agile is more than just a development methodology –this new approach to developing and delivering working software requires an organizational change in mindset.
At IBC, our agile development services and solutions help organizations achieve the multiple benefits of an agile methodology by addressing the technical, managerial, and organizational components of moving to a new approach. If you’re interested in learning more about how to move your organization towards an agile development methodology, how to get started with a new agile team, or tips to work with your project sponsor, please contact us. We can help your organization realize the benefits associated with the “Agile PMO Manifesto” and make software development projects rewarding for everyone – not just the folks trying to do less documentation. In doing so, we can convert your organization into believers, just like me.
Enterprise Architecture (EA) has developed a reputation. We’re often reminded of this when in a meeting with senior business leadership and someone explicitly mentions the EA program. Eyes roll back in heads, quick loaded glances are exchanged, an audible exhale is heard as if to say, “Ugh. Not this again.” If you’ve seen one of these reactions or maybe even all three simultaneously (unofficially known as the EA Trifecta), unfortunately you are not alone. EA programs in all corners of business and government are struggling to demonstrate substantial organizational value and achieve true enterprise buy-in and acceptance.
It is not for a lack of trying. Organizations that have decided to invest in EA programs are usually making substantial personnel (both internal resources and external consultants) as well as software investments in support of their EA programs. In addition, organizations typically incur significant indirect EA costs in the form of stakeholder meetings and presentations. Many enterprises have started to take a hard look at their EA program to assess whether the EA program is worth the investment. It has left organizations asking themselves, “What’s wrong with our architecture?”, a question that Frank Lloyd Wright most certainly asked himself more than once.
As IT professionals, we see organizations experiencing a variety of challenges with their enterprise architecture programs. There are many potential pitfalls when it comes to establishing a value-driven EA capability. If you find yourself struggling to comprehend what’s wrong with your architecture, consider the following questions that might uncover some of the issues preventing your EA program from providing real enterprise value.
Over the past two years, organizations of all types and sizes have adopted the agile methodology for the delivery of projects in some or all of their programs. While many are recognizing successes and tangible improvements from agile software development, many others are either struggling with their implementation of agile practices, or are simply not reaping the benefits that they could and should. In our experience, there is no “one size fits all” agile approach or implementation, and it is important for organizations to recognize that fact and adjust how you use agile to fit your programs and your processes. Also key is setting realistic expectations and defining specific goals for your agile adoption, and not simply expecting agile to solve every challenge or struggle you have in your software development process. Through your agile implementation planning, we encourage you to be cognizant of a handful of common pitfalls that we have seen contribute to marginalizing our clients’ agile implementation success.
Agile in name, not in practice
Agile is a cultural shift, and it does not happen overnight. It takes a well thought through plan to successfully migrate to using agile. Far too many organizations are effectively just putting an agile label on their mostly waterfall methodology, and not truly embracing the change. In order to reap the benefits of agile, you need to commit to and focus on adopting its fundamental principles and putting them into practice. Specifically, achieving continuous value delivery throughout every aspect of your project, and ensuring that all of the activities that your teams are performing are contributing to adding value and delivering a better product. Changing processes and procedures can be uncomfortable and challenging; but really taking the time to consider how you could adapt and change your legacy requirements and processes to be more agile can enable your organization to actually deliver with a more orthodox agile methodology and achieve the continuous value that it is intended to deliver.
Key resources not dedicated and roles not well understood
Agile as a methodology cannot work without the people in place to execute it. The Agile Manifesto reinforces this by stressing “Individuals and Interactions.” There are three specific roles in an agile delivery team – Product Owner, Scrum Master, and “the team” – and each need to have both a clear understanding of their responsibilities, and to be dedicated to a single agile team if possible.
Product Owner: The most common issue we have seen with regard to the Product Owner (PO) role is the PO being responsible for other, ongoing “full time” tasks, in addition to his agile responsibilities. When the team needs a clarification or prioritization decision, often the overburdened PO is unavailable. Other product owners also struggle with the concept that their role is that of the single sign-off and decision-making authority, and thus if they need to enlist feedback from others within the organization, they need to do that in advance of when decisions need to occur.
Scrum Master: For the Scrum Master, dedication issues can arise when organizations ask a team member or a product owner to simultaneously play the scrum master role. Scrum masters have unique responsibilities, and ideally should be distinct from the Product Owner and “the team.” The scrum master role requires an individual who can facilitate the team’s progress and tempo, shield them from interference, and work across stakeholders and with the product owner to set project direction. For organizations indoctrinated in the waterfall or other non-agile methodologies, this shift from a work management role to a work facilitation role can be a difficult cultural adjustment.
“The Team”: The biggest issue we see with ‘the team’ is not having core resources fully dedicated to one agile team. In reality, there will be resources whose roles are to support multiple teams, given their individual contribution type or skill; the key with these resources is to manage the dependencies across teams so that each team is getting the involvement they need and plan for. When creating your core teams, building a cross-disciplined team (covering all core technologies) is ideal, but often when organizations have one or a few individuals with a unique skill set, they tend to ask them to spread time across teams within a given iteration. Dividing key resources across multiple agile teams at once could result in the following adverse effects:
- Teams are unable to properly estimate velocity, as they don’t get the benefit of consistent presence and team member continuity;
- Teams plan for or commit to work that they are unable to accomplish in a given iteration because the resource is not available or gets pulled into another effort;
- The morale of the overstretched resources suffers, as they are not benefitting from the team atmosphere that agile fosters, and may feel over-utilized with multiple priorities always in front of them.
Organizations adopting agile should strive for dedicated core resources as much as possible —as we have seen, a focused, full-time product owner, a scrum master skilled in facilitation, and a committed, autonomous team are vital to agile success.
Inadequate sponsorship and stakeholder engagement
Agile promotes collaboration and engagement across the organization in order to ensure that the highest priority, highest value work is accomplished first, and that the right people are available when needed to support that work.
Given the magnitude of the cultural shift to agile from other methodologies, stakeholders from throughout the organization must commit to and sponsor the move to agile. They should be “on board” and supportive of the new methodology, and take tangible steps to foster the potential process and technology changes necessary to make agile successful. Examples include supporting the modification of the gate review/approval process, promoting technology changes to support continuous integration, and understanding and adapting to the differences in levels of forecasting and reporting that the agile process can and should provide. Securing executive sponsorship up front is also critical to setting the right product vision and shaping the initial scope and goals of the agile program. These examples also further illustrate the need for proper stakeholder and executive expectation setting up front about what it takes for an organization to fully and successfully adopt agile, so that once the agile train starts moving, it does not derail because of avoidable concerns.
Furthermore, taking the time to properly educate stakeholders at the outset of any new agile implementation will help ensure that everyone in the organization not only knows what agile is, but also and more importantly understands why you are doing it, and what their role is in the new method. Providing this level of understanding will help promote agile adoption.
Ceremonies not being properly executed
In any methodology, there are a number of phases, processes and procedures that define the execution framework, and agile is no different. Understanding the framework itself is key, but more importantly, you need to understand and value why each step or ceremony is part of the methodology, and use that understanding to effectively leverage that methodology. In our experience, there are certain agile “ceremonies” or steps that are often neglected, leading to unattained value:
- Daily stand-up meetings: Too often, teams use this meeting to report status, because they are so used to status meetings from previous projects and traditional methodologies. This meeting is in fact not intended to be a status meeting, and its purpose is actually for the team to communicate with one another, not to provide status externally. Discussion in this meeting should be from the team, and only focus on answering three questions: what did I complete since the last meeting, what am I doing today, and do I have any obstacles that I need help removing? Furthermore, any issues or problems that are raised should not be solved during the meeting; team members should determine a time after the meeting to further discuss.
- Sprint Retrospectives: The issue we have seen with the sprint retrospective is that its value is often overlooked, as teams are already looking ahead to the next sprint and do not see the benefit of spending time to conduct the retrospective. In reality, this is a key ceremony and an enabler of the important “inspect & adapt” principle of agile. This meeting is a time for the team to discuss what went well and where there may be room for enhancements or changes, so that they are continuously improving sprint over sprint, and furthering the achievement of value through their agile delivery.
It is important for organizations that have adopted agile to realize that these and other agile “ceremonies” are not simply empty rituals, but are an integral part of agile success and are rigorously followed by successful teams.
Not properly scaling the methodology
Most of the available agile scrum training and guidance is focused on how to effectively operate a scrum team or run an agile project. However, recently we have been engaged with many clients that really require more of a program-level agile guide, which recognizes the importance of integration across multiple concurrently running agile teams, the need for common and centrally-defined architecture, and aligned release milestones. Without this program-level agile framework, your organization may have highly performing individual agile teams, but still not be able to deliver the tangible value earlier because of lack of alignment across teams, missed dependencies that cause feature delivery delays, or the creation of technical debt realized from the lack of consistent and well-thought out architecture.
To mitigate these concerns, we have leveraged the concepts and methodology prescribed by the Scaled Agile Framework (SAFe), which stresses the recognition of Enterprise, Program and Team level agile adoption and processes. One of the key elements of the framework that we often see organizations overlook is the need to create a program vision and product roadmap, as well as to define incremental releases and feature sets. Establishing this definition up front helps deliver tangible value earlier to stakeholders, because it aligns work across agile teams to a unified feature set and sets the vision for all teams together, as opposed to individual goals.
We strongly believe that the benefits of agile are only realized if you implement it in a way that will work for your organization, reflecting your culture, your people, your technology, and your processes, and at the right time, with the necessary support and plans in place. To help you realize these benefits, we also suggest that organizations consider enlisting the help of a third party expert to provide an agile assessment or capabilities workshop to help your organization avoid some of the pitfalls we explained here, and to sure up your framework for agile success.
At IBC, we bring a wealth of experience and expertise implementing technology solutions using both traditional waterfall and agile approaches. We are also helping organizations determine the right agile approach for them, and helping them to course correct their waterfall to agile transitions in a successful manner. We bring seasoned personnel, including many certified scrum masters, to address our client’s implementation needs. To see how we can help you, contact us today.
In October 2013, IBC, a DBS Company (IBC), was formed as a result of the merger between DominionBusiness Solutions, Inc. and Integrated Business Consulting, LLC. Based in Reston, Virginia, our combined company brings the same small-business values and focus that drove our individual success, but now with a broader reach and an expanded set of joint capabilities. As 2014 kicks off, we pause to reflect on our past success and look ahead to our promising future.
Reflecting on the past of each company reveals a similar history and a shared commitment to the success of our clients. Both companies were founded with the idea that customers want and deserve more than just contractors who support their projects. We shared the belief that true value comes from those organizations that treat their clients as strategic partners and work collaboratively to solve their business challenges together as a team. Furthermore, we focused on empowering our clients by delivering solutions that reflect a shared vision and position our clients for long-term success. Applying this philosophy and approach helped power the success of each of our legacy companies from their respective beginnings until now.
Founded in 2009, Dominion Business Solutions (DBS) was established as a management and IT consulting firm focused on solving our clients’ most complex and mission-critical challenges. DBS was launched by Dan Maguire and JP Foley with the support of a handful of trusted colleagues, re-building some of the same leadership team that had enjoyed tremendous prior success growing and exiting another IT consulting business. Unlike a traditional IT services start-up, DBS leadership invested early in expanding the management team, operations, and resources of a much larger company – building the base infrastructure for the much larger company they planned to become. Subsequently, DBS established itself as one of the region’s fastest growing and award-winning providers of technology solutions to both public sector and commercial clients, most notably receiving Consulting Magazines “Seven Small Jewels” award in 2012.
Over our four-year existence we expanded our solution expertise and established a reputation in the marketplace for consistently delivering innovative and proven solutions that enable our clients to realize significant performance gains and achieve lasting results. While DBS was able to achieve substantial growth in our relatively short corporate history, we saw in IBC a potential partner with a much more established brand and successful past performance with prime government contracts and relationships. “We had enjoyed a period of substantial corporate growth, both solution offering and industry and agency vertical expansion; however, much of that growth was as a strategic teammate within the federal marketplace as opposed to prime contracts” said JP Foley. “We knew that in order to successfully compete for larger and higher-visibility federal prime contracts and commercial enterprise-level opportunities, we needed additional depth of capability. Merging with IBC, a company we had successfully teamed with in the past, was a logical and strategic solution to that goal.”
Following a similar path, Integrated Business Consulting was founded in 2003 with a focus on providing deep functional and technical Enterprise Resource Planning (ERP) services. IBC’s founding partners, Todd Barber and George Hagstoz, found a crucial need in the SAP Public Sector space for Platinum Integration Experts. They believed that the key to a successful Federal SAP Implementation required a strong understanding of the SAP product suite, coupled with a deep understanding of the Federal Financial management process. IBC’s original success was developed leveraging senior SAP implementation experts in the initial implementation of the Internal Revenue Service, US Army, and NASA. Over the course of 10 years, Integrated Business Consulting expanded our service offerings to include Program Management Office Support, Audit Readiness, and Independent Verification and Validation across other ERP packages in addition to SAP.
In 2009, IBC began focusing on prime contracts and was able to secure a number of new clients including the FCC, USDA, and GSA over the past 2 years. “In looking forward at the challenges faced in the Federal Sector, we felt it was important to expand our service offerings and capabilities quickly to increase our depth in supporting our customers. Having partnered with DBS in the past, we knew that both companies had a similar culture and shared business goals. This synergy developed through the merger allowed us to quickly achieve our growth goals with minimal organizational impact.” said Tim Spadafore, Managing Principal.
Overall, the merger represented a great opportunity to unite the distinct cultures and experiences of our companies through our shared philosophy and commitment to outstanding client service. Together, we are now able us to better serve our customers across all industries and solutions, while also providing new opportunities for our employees to take on new challenges and responsibilities.
As we look forward to the future, we share a sense of excitement about the opportunities now available to us as a result of the merger. Our combined strengths are positioning us for a new era of sales, business development, and opportunity pursuit. A great example of this is our recent bid to manage a large-scale SAP implementation at a major Federal Agency, requiring a project team of almost 100 personnel. Neither legacy firm would have been capable of bidding the opportunity alone, but as a combined entity, we were able to author a strong, credible proposal and garner the respect and confidence of both the client and our large business partners. The ability that we now have to pursue opportunities of this order of magnitude will be a tremendous driver of our growth in the coming years.
Another exciting result of the merger is the opportunities it creates for continued career growth for our employees. As we now have nearly double the clients and projects, employees will have tremendous opportunities to learn new skills, contribute on different engagements, and find areas for career growth not previously available. Also, our expanded internal operations capabilities are now supporting new initiatives such as formal (and informal) mentor programs and improved training and education paths, that will help ensure that employee has a clear path for career growth and enhancement.
A final thought related to what this merger means for us as we look ahead, is the concept of “stability”. Consulting firms operating in the current economic environment, coupled with the uncertainties of the Federal Government, face significant challenges and risks. As a small business, even the smallest of risks can be real and impactful. While our newly merged business isn’t free of these types of factors, we are much more able to adapt and incur both the positive and negative fluctuations of our business. The “new” IBC is strong, stable, and poised for sustainable growth.
“I am personally very excited about this merger”, started Dan Maguire, Managing Principal. “It is clear to me that the resulting combined company provides a solid foundation for our employee’s careers and it will tell a very positive story for future recruiting. I am very optimistic about our future.”
Subscribe to Dominion's Blog via Email
- Blazing a Bright Path to the Future as TeraThink
- As if DevOps was Not Enough…DevSecOps
- Building the Local Agile Community at AgileDC 2017
- Looking at the Future of Digital at SAP TechEd 2017
- Congratulations Laurence Hart, The Information Coalition’s 1st Honors Fellow
- Dominion Walks to End Alzheimer’s
- People First These Days in Information Governance
- Fall is Coming So It Must Be Time for Dominion’s 2017 Veteran’s Day 5K Race