Comments Off on Uniting Software Professionals Revolution Conference June 1st and 2nd 2017 Virginia Beach
2 56 DAYS | SPEAKERS
Uniting Software Professionals
RevolutionConf is a two-day, platform and language agnostic, software development conference being held on June 1-2, 2017. This year, we are taking over the beautiful Wyndam Virginia Beach Oceanfront. With 15,000 sq. ft of conference space, on the world famous North End of Virginia Beach, VA, we are hosting talks from regional, national, and international thought leaders.
RevolutionConf is organized and supported by the board members of RevolutionVA, a 501c3 non-profit based in Norfolk, VA. The goal of RevolutionVA is to unite software developers in the mid-Atlantic region through conferences, and career and learning opportunities.
So I bet that headline grabbed you right! Over the years I have been noticing the sheer mountain moving that has to be done to successfully move projects, initiatives, changes, and or innovations forward. Ever tried moving a mountain before….talk about a workout! There are two common areas I see being a root cause of these mountain moving activities
1. Organizational Charts
2. Manager responsibilities for developing People.
Yes I said it managers developing people. I also said organizational charts too. I know this may offend some people right off the bat, but give me a chance to explain and present an alternate idea and you may want to change your business to actually get projects done.
So before we begin I want to present a model for designing a new business model to actually solve the problem most businesses are having in the areas of getting projects done and developing people. Below is said such model after the model I will explain the components that make up this model:
Initiative Based Business Structure
Now lets get into the good part the people development side of the problem. The way our organizations are set up to day is that most managers are strapped with moving projects or initiatives forward as well as developing employees, the real backbone of your organization. Most managers that are put in these positions are ill equipped for the job. Now I don’t place all the blame on the managers themselves, but more on the organization that have put these managers into positions with very little initial or ongoing training to build up this hard and soft skill. Additionally there may be some issues with the cultural and political factors of moving up the ladder to manager, but we will leave that for another post.
Mangers need to get back to moving initiatives forward! This is really what this role is intended to be doing for your organization. Now to solve the void by removing people development from their job description you need to activate a whole group of people that have gone to school, received training, and have sharpen the people development skill down with art and science. Who are these people you say, they are your Human Resources, Recruiters, Organizational Effectiveness, and Talent Management people. Yes they have to be activated to begin the true transformation of getting your project work done and developing the people at the same time. Get the managers back to getting projects, initiatives, and innovations implemented and your “People” departments back to developing your people (or if you are a buzzword addict Talent). The model above shows that your People Developers are assigned 5-10 people to manage their development. They are responsible for training programs, reviews, long and short goals, hard skill progression, and soft skill proficiency.
Unfortunately, in today’s world we strap the manager with initiative implementation and people development. Now don’t get me wrong about 10% of our managers can pull these feats off with eloquence and grace, but that does not seem like a high percentage for running an effective organization. If we get the manager and workers back to delivering initiatives and people developers back to developing people, most organizations will be unstoppable around producing for their employee, customers and shareholders.
The Organizational Chart
Secondly, lets look at the organizational structures of most businesses. Each focus area is usually placed into a macro-silo such as HR, Marketing, Customer Contact Centers, Product Sales, Legal, IT, etc. and within that macro-silo many micro-silos breakdown into smaller chunks of work. I have even seen micro-silos within micro-silos. Try this activity on to see if this perspective fits your company. Take all your micro-silos for a particular macro-silo and place them along the top, then along the side place another macro-silo that you have to get projects or initiatives done with and it’s micro-silos. Now each box in the grid represents processes that need to get done. Start picturing the grid below and this gives you the visualization of inputs to outputs of each intersecting box. You thought rush hour traffic in LA was bad, try gaining approval for adding a process or field to a screen…..
Goal Achievement Grid-Lock
Now that was two macro-silos for one project or initiative. Multiply that by 10 to 14 times and you wonder why projects or initiatives take mountain moving efforts to get done. That is just the structure I haven’t even sprinkled on top Goals, Objectives and Metrics for success. Typically each macro-silo is held to four or five of these, then each micro-silo is responsible for coming up with their own Goals, Objectives and Metrics for success that help accomplish the macro-silos Goals, Objectives and Metrics for everyone to receive their good review scores and bonuses. Now in most cases one Macro-Silo’s Goals and Objectives are in direct conflict with another Macro-Silo’s Goals and Objectives. This usually turns people development and initiative success into one big hot mess of “Your Goals are not My Goals!” This has to be solved! The “Same Goal” circle is very rarely achieved and even rarer of intersecting that smooth within the current business structure. Typically I see this happens on skunk works projects or proof of concepts, but usually are not scalable for success across a whole enterprise.
In this new model an organization’s macro-silos would turn more into a communities of practice. With a community of practice individuals within these practice areas share role expertise, skills, and subject matter expertise. When you center all these people together and sharing is the rule of the day and resources are rewarded for this activity, you have communities of resources that are activated for initiative or project work when their skills are needed! When Managers that need to get an initiative off the ground and implemented they go to these Communities and build the project or initiative implementation swat teams.
These community members are 100% dedicated and are there from the start to implementation. They bring their expertise as well as the expertise of the community. These individuals are there from start to finish and finish means transitional points to operations then support. The main problem it solves is the initiative or project team in dedicated to getting the initiative implemented for the organization and not in it for this macro-silo or that macro-silo and avoids the “Your Goals are not my Goals” gridlock! The teams are in it for making the organization successful for the employees as well as their customers.
Now put all this together and these are big changes for your organization, but lets face it the last 50 years of the same structure has not really systemically harnessed all the potential intellectual horsepower people have, that we definitely need going into the next 50 years. I know this always sounds scary, but we have to completely revolutionize our markets, products and services. This structure will allow the right people doing the right things based on what needs to get done for the organization. This can work for any initiative marketing, HR, technology, operations, support, supply chain, consulting services, logistics, financial services, etc.
The one area I am still investigating and gathering information are the areas of operations and support. More of these types of organizational structures need to centrally focused and not moving around from initiative to initiative to initiative. They are definitely vital to the initiative or project success to be involved from day or step one though. They will provide information for transitioning, training, user acceptance, etc. They are just not 100% dedicated because they have to be 100% dedicated to business operations and support. More to come on this subject too.
Please provide your thoughts, challenges, questions, and out right your Wrong comments below! Looking forward to see what happens.
Comments Off on 4 Tactics to evaluating, buying, and implementing Vendor technology packages
Being a Business Analyst nothing drives me more up a wall when I hear “Oh it is a vendor package, we don’t have any requirements.” My first response to that is Really? Or depending on the political and relationship of the environment a little attitude will be thrown in with the response of Really? In this post I will lay out 4 tactics as to why this thought process dooms your project before you even start. Yes it dooms it, sorry no nice way to put this. In my career I have seen many many many vendor technology packages suck companies dry because of not following these 4 tactics. If I added it all up in the last 10 years, I have seen at least $500 million dollars wasted because the company did not know the technology they already have, what they really wanted or what they really needed.
This goes back to very simple premise; know thy business! Sorry to break the news, but your business is run by good technology and good technology selections. Using these 4 tactics when evaluating, selecting and implementing a Vendors software package you will save time, money and whole lot of headaches. The tactics focus more on using a more iterative, collaborative, and co-creation methodological process (Please insert your methodology definition of what that is, most software development lifecycles SDLC’s are basically all the same with different terms, thought leaders, and definitions. These tactics still do not change).
1. Understand your requirements from a business scenarios context:
Organize all your business scenarios and collaborative processes and technology that will be touching the Vendor package. Yes in todays world there is no longer the black and white of process vs technology. They are and always will be interwoven. No more of this separation of process from technology! Sorry “I only worry about the business process without technology” people! The business scenarios will allow for the project team to put information into containers for easier decomposition, decision making, gap identifiers, and nice to haves highlighting. Without organizing into containers the project team ends up trying to make decisions on a laundry list of requirements and never can answer the question “Do we have everything we need and want?” Having this layer of information will help people find vendor software packages that support their business scenarios. Below is an example of how to model those business scenario containers.
The Business with Circles and Stick Figures
You also will avoid buying software built for the aviation industry and retrofitting to use in financial services (this never works, I have seen this once). This model will help you organize around decisions based on core vs nice to haves. It will also show you how many different users there are for a particular implementation. It is simple circles, arrows, and stick figures to depict how big is this “bread box”(this is the term thrown around when trying to figure out scope). Gather as much information from as many different users, process documents, technical specifications, and industry users as possible. At all costs do try and avoid requirements gathering overload (this is the art that a good Business Analyst brings to the team)! Estimated time for producing a model like this 2-3 weeks.
Now that you have you have identified your business scenario containers you can beginning filling those containers with requirements based on the process diagrams each business scenario has in regards to business rules, functional or user interface requirements, data requirements, non-functional requirements, and security and information requirements. Within the world of software development a project team could provide details of your business scenarios with 57 different types of requirements, that all come with their own set of attributes. All these requirement types make up the ecosystem of requirements management including traceability, impact analysis and conceptual design of the technology. Here is how the information is linked together to understand your whole picture of requirements:
How Requirements Trace
This is typically how requirements trace to each other. The names may slightly differ depending on the methodology you are using, but the model will be somewhat the same across a multitude of methodologies. These are the details that will fit inside each one of the circles above according to your business scenarios. Keep in mind, some of the business scenarios above kick off other business scenarios within the model, that is ok! This will help establish input and outputs of successful completion of that business scenario. This is why having a team that understands the complexity in very usable containers is key to evaluating, buying and implementing vendor software. Without this, good luck and may the force be with you……
The Requirements Management Hard Work Model
This model depicts the process a project team goes through to manage all the information within the business scenario containers. Without this for guidance, project teams often find themselves in chaos, analysis paralysis, or worse stuck on what comes next. All three paths lead to wasting time, money, and resources, not only the Clients, but the Vendor also.
2. Download a free copy make screen shots
This step will be critical in your evalaution process. Start taking screen shots of evalaution copies of software and bounce your business scenario processes and requirements up against the technology you are researching. Yes I know, this causes rework. You have this either way. I would rather do a whole lot of rework on information, than in production when your audience can now see the garbage on the lawn. It is not pretty, trust me! I also said this was not going to be easy and take a couple of hours to do either. Taking the information from tactic 1 will help you bounce your business scenarios up against the vendor’s interpretation of your industry. Start running through your business scenarios in these evaluation copies.
At this point start refining your requirements. They are not set in stone and never will be. If you have a multiple disciplines (SME’s, PM, BA, Tech Lead, Architect, Infrastructure Architect, Support personnel) co-creating you ensure continual buy-in and a successful implementation. You may even discover some requirements for your business using two different vendor packages. Document this information and use them in tactic 4. This information can sometimes lead to changes on the vendor side, which will lead to a better partnership of trustworthy sharing and collaboration (This is a behavior that is missing in most vendor client relationships to begin with)
Sometimes you may find a software package has found a better way to do your business scenario. That is ok! Your business does not always have to have all the answers to weaving business scenarios and technology solutions together. Do not get caught up in thinking this is where your competitive advantage lays for your business. It is your people and empowering decision making with the use of the information in and out of the vendor packages is where your competitive advantage lays. I have seen where companies have gained huge competitive advantage by allowing the vendor package to dictate the process and technology of particular business scenario. The reason is the company gets back to focusing on delivering top notch business services and products to their audiences, this is where you earn your keep with your audience. Additionally, it makes getting to market a lot shorter.
The Vendors you buy packages from focus on one set of processes and technology for a particular industry. These companies live and breathe making the industry specific business scenarios the most efficient, intuitive, and easy to manage within their software package (for the most part….). Take salesforce.com for instance. They focus on making the sales process the most efficient it can possibly be with sound business scenarios and technology to support those business scenarios. Your business scenario is selling a certain product or service to your audience. Let the experts in the sales process and technology worry about that while you sell the product, that is how your business makes money. Your business does not make money by re-engineering your sales process, so partner with the process and technology experts that live and breath certain business scenarios, trust me finding these partnerships will lower costs and increase revenues! I hope this analogy make sense? If not drop me a comment and we can discuss further
3. Get your Business Analysts, Testers, Developers, Subject Matter Experts, Infrastructure, and Project Management disciplines collaborating on the information:
This tactic is probably the most difficult to manage or implement depending on the whole culture of your organization, the behaviors of your people towards collaborating and sharing, and do your disciplines have the street and book smarts in regards to discipline collaboration. A company can state that they are agile or iterative until the cows come home, but if the people don’t process the information in a culture of collaboration and co-creation it just isn’t true. Disciplines must have the comfort and trust built up in their relationships to encroach respectfully into each others disciplines. I show these overlaps in the Business Analyst 3.o post.
The team you pick for performing these tactics must be full time on this effort, any thing less you will not make it a priority and the project will fail. This tactic also brings everyone to the table for the demonstrations of the Vendor package to satisfy all parties involved and will facilitate making a good technology decision. These decisions can not be made in the vacuum by strategists or leaders that will not be using this package on a daily basis. Great, the vendor package has great executive reporting dashboard for executives, but the tactical and operational information going into the package is garbage and slows down your business scenarios. Garbage in Garbage out, this affect is more prevalent in vendor packages, if the decisions to buy and implement is done at a too high level away from executing the actual business scenario.
4. Take control of the dog and pony shows based on requirements
This is where your gathering, analyzing, and scope definition will pay huge dividends. If you allow the Vendor to run these reviews you will be sold to. This is not the fault of the Vendor! They are trained and coached to sell the cool features that cost money. The fault really falls on the Client for not preparing, understanding, and knowing thy business working within a technology platform. This step is where Clients can take back the control and get what is needed and on occasion what is wanted for their business scenarios.
This collaborative demo really makes for a good working relationship with your potential Vendor. Let me explain. The Vendor will not have to waste time helping the Client figure out what they need and can focus more on being a true partner in consulting, recommending, and creating for the Client based on a clear vision. The Client should not be paying $200.00 per hour to figure out their own business…..this to me does not make good use of the of a scarce resource called money!
An additional suggestion I would make is have two demonstrations of the vendor software package. The first one would be completely understood as a time for the Vendor to do their sales, dog and pony show, and offer up their road-map for their product(s). The second demonstration would be completely controlled by the Client with reviewing the product through the lens of their requirements, process flows, and wants and needs of the product features based on their business scenarios. The mood and behavior of the second demo should be collaborative, co-creative, and sharing of “garbage on each others lawns.” All along the way refining the requirement information. There may even be a resource on the project team completely dedicated to keeping information up to date. This is where your triple AAA BA’s learn their craft!
Implementing these 4 hard work tactics (yes sorry to tell you, you will be doing some hard work here, no silver bullet!) will pay dividends for your short term and long term success for your projects to implementing vendor technology packages. These techniques can work for Software as a Service (SaaS), Off the Shelf Install products, Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and Social Technology Ecosystems (sorry no silver bullet in this area either). I have seen both sides of this equation and utilizing these techniques has led to buying and implementing the correct technology for true return on investment of time, money and resources.
If you have additional techniques that you have seen be successful on a project please leave a comment. This old dog loves learning new tricks! One added thought on these 4 tactics is swap out the word “business” for “technical” in front of scenarios and it works the same way just a slightly different type of language used in your requirement statements. So you technical infrastructure (servers, routers, modems, switches, wireless hardware, pbx’s, ivr’s, mainframes, etc.) folks we have you covered too!