SWOT: The Analysis

Ok so you've gone out and performed SWOT now what?

Assuming you want impact in your recommendation to your client, using the following approach with your SWOT will give your recommendations credibility. Keeping in mind that a SWOT is both internally and externally focused, by following these steps, your proposal will more accurately quantify the thoughts and concerns of your client.

Opportunity and Threats

In order to identify the Threats and Opportunities of a project risk analysis tools from the Project Management Institute can be used. PMI has identified, within the text “Project Management Book of Knowledge, Fourth edition”, two(2) risk analysis tools that can be used to identify the most relevant threats and opportunities: Impact Perspective and Impact Matrix.

Impact Scale

The Impact Scale is a five point chart that can be used to assign a weighted average to various metrics, resulting in a value representative of the impact to an organization.  I have altered the metric from the Project Management Institute’s definition, seen below,

1. Monetary Value - will be measured in terms of increased revenue (opportunity) or cost (threat) to the organization.
2. Time - metric is in reference the time savings enjoyed as a result of exploiting a opportunity or as a result of addressing a threat. 
3. Market Exposure -  they provide to the organization, as a means to strengthen the brand while a threat will be examined for negative impact.
4. Process Efficiencies - has been identified as those opportunities that provide improvements, while threats are those that decrease efficiency.
5. Relevance - that refers to the overall impact on business strategy and/or processes.

For each identified opportunity and threat, the formula used to determine the impact scale will be as follows:

Probability and Impact Matrix

For each specified opportunity and threat, a thorough analysis of each item will identify a probability of occurrence. In conjunction with the Impact Scale value, the probability will assist in ranking the opportunity or threat.  The rank value is calculated with the following formula:

This Probability and Impact Ranking will then be used to plot the opportunities and threats on a Probability and Impact Matrix. The matrix will highlight three sections: high impact areas (red upper center area), moderate impact (white middle sections) and the low impact (green outlier sections). Once each item is plotted, recommendations will, dependant on resources available, focus on items in the high and medium impact areas as to ensure a highly focused solution to the opportunities and threats the immediately faced by the organization.

Opportunities and Threats:

For each opportunity and threat listed in the SWOT, the probability and Impact are taken into account and if you employ weightings based on who provided the response, those are calculated at this point. Once summarized, they are plotted on the Probability and Impact Matrix to determine a 'Score'. This score essentially will assist in plotting the items onto the matrix.

In utilizing the Impact scale's five metrics to provide a structured analysis, each of the opportunities and threats are analyzed and plotted. Each item is measured against the same criteria, thus providing a universal scale that we used to devise a ranking. The weighted Impact Scale value was then multiplied by the probability of the threat, or opportunity occurring, which resulted in the Probability and Impact Ranking for threats and for opportunities. Sample rankings have been plotted in the image below:

The ROI

The Probability Impact Matrix provides a structured means to perform qualitative analysis. The items identified within the matrix are ranked in order of impact (very low, low, moderate, high and very high) and probability of occurring. By plotting each item on the Probability Impact Matrix, we can quickly identify which items are classified as: high impact, moderate impact and the low impact.

I hope this helps and not hinders.

-Project: ROI

SWOT: The Concept

 You wanna talk about SWOT? Seriously?

Chances are you've seen SWOT hundreds of times and learning that its an acronym (Strengths, Weakness, Opportunities and Threats) is not new - you're no stranger to it. However, after the client filled out the forms what did you do with it?  Did you simply summarize it is a paragraph or two? Or worse, you just appended it to a proposal? I am hoping to go beyond the definition of SWOT and provide you tools that you can use to provide that added value to your requirements gathering process.

No. Not that 70's TV show... ...its not even spelt the same.

The Approach

In gathering requirements from your client, you will inevitably try to extract what they think is needed and what they really need. A SWOT is your clients thoughts. It is what the client perceives their need is or simply what they want as a result of the project.

With this in mind, a SWOT is useful as it will put into perspective the needs and wants of all the groups surveyed and will help you better navigate the project. You will be able to address the stakeholder concerns preemptively thus mitigate the risk of not addressing true needs.

Let me draw you a picture...

The SWOT diagram to the right shows a SWOT properly classified with: Helpful vs Harmful External vs Internal Strength is helpful as it helps identify things done well whereas it is focus on the organization rather than market. Weakness is quite the opposite, if left untreated, it can be harmful in the short/long term but this is an aspect that can be dealt with internal to the organization. Opportunity and Threat are both market factors. Opportunities can be exploited while Threats can be mitigated, addressed or avoided.

THE ROI

The Goal of these posts will be to help you determine if a SWOT is for you and if it is, how can you use it effectively. The SWOT is a tool that is widely known but not widely used effectively. The ROI will be more focused projects, properly defined requirements and the beginnings of a stakeholder map.

I hope this helps and not hinders.

-Project: ROI

Just Picture It!

In zero words or less, tell me what this means…

There are countless ways to approaching project documentation. One of the ways we are going to review is the use of, you guessed it,  diagrams!

A well documented problem or proposed solution is ideal for developing a common understanding (stakeholders), providing new hires a starting point, and monitoring/mitigating impact of scope creep. By not only developing but by using detailed project documentation, all project stakeholders with access to this information can acquire a common understanding and contribute to the project in constructive ways. This contribution may lead to 

Changes in the project scope - change isn't bad - it just needs to be managed. The earlier in the project the change is caught, the easier it is to make the necessary adjustments.

Identification in errors in design - Don't be afraid - this is part of the reason we write documentation. Changing a design in your documentation is FAR easier then making the correction in the testing cycle.

Img = (string) 1000

Have you ever read project documentation helped cure insomnia? Not everyone can be a wordsmith; however, using diagramming techniques provides you with the ability to accurately convey your intentions and helps your audience to understand through visualization.

For example, a project that requires a process to only go through steps A and D may be quite easily be described and understood. But after a few project meetings and/or iterations, the simple process may morph into one that requires steps A and D going through B with contributions from process C.  Now the process becomes more difficult (not impossible) to describe with only text and may be glossed over by the key parties that should pay close attention.

Tools? We don't need no stinking tools….

Now the key to diagramming effectively comes down to using the right tool for the job.  Knowing what diagrams and diagramming tools are available will help you in your quest to convey specifications, requirements or your understanding of a situation. The list below provides a little insight into the numerous diagrams that are at your disposal. 

YOINK!

Seeing as this is a 'blog' and not a doctorial thesis, I 'borrowed' content from Smart Draw .  I downloaded their trial version and I love it. It has a similar look and feel as MS Office - so you can find your way around, the diagrams are intuitive and easy to use!

Considering I've been using Visio for my diagramming needs - I'm going to start a petition to get this tool in my office.

Balanced Scorecard A Balanced Scorecard allows a company to divide a vision, or overall objective into the smaller pieces or necessary steps that will allow it to occur. These pieces may be phases of the process, or the project from the perspective of different departments of the company, but in any case it should be a continuing cycle that will continue working towards a single overall goal. The Balanced Scorecard is especially useful when trying to communicate the role of a team or company in accomplishing the overall mission. It can also be helpful in tracking the progress of a goal by the specific parts that will make it possible. http://www.smartdraw.com/resources/glossary/balanced-scorecard/
Boston Consulting Group Matrix A BCG Matrix, or Boston Consulting Group Matrix, allows for a realistic plan of finances in a manner that is more diverse using symbols and focusing on investments. Each investment or product is plotted in one of four positions of the matrix based upon the Market Growth Rate versus the Relative Market Share. A BCG Matrix is best used to focus on many different aspects, such as products, of a company at once.
Cause & Effect Diagram (Fishbone /  Cause + Effect   /  Ishikawa diagrams ) Originally developed by Kaoru Ishikawa to visualize the causes of a specific event, the Cause and Effect Diagram has come to be known by several names: Cause and Effect, Fishbone, or Ishikawa diagram. It is one of the seven basic Quality control tools, and has become commonly used to determine components needed for a desired outcome. The main issue is written in a box that is typically in the center of the right edge of the page. A line called the "spine" or "backbone" extends to the left starting from the edge of the main box. Branches angle off of the spine, each representing a cause or effect of the main issue. Each of these branches may contain additional branches. A Cause and Effect Diagram is used to examine why something happened or might happen by breaking up the issue into smaller categories. It can also be helpful to show relationships between contributing factors.
Mock-ups Using Mockups feels like drawing, but because it’s digital, you can tweak and rearrange easily. Teams can come up with a design and iterate over it in real-time in the course of a meeting. Product managers, designers, developers, and even clients can now work together in the same tool to quickly iterate over wireframes, before writing code http://balsamiq.com/products/mockups
Strategy Maps Strategy Maps are a summary of what a company plans to do in order to improve its business. The map is similar in structure to that of a Swim Lane Diagram and in concept to that of a Balanced Scorecard. It has swim lanes (although they are horizontal rather than the usual vertical), or visual category divisions, representing different perspectives of the topic. These perspectives are typically Financial, Customer, Internal (business) Process, and Learning and Growth, following the Balanced Scorecard divisions. Then boxes representing different aspects and ideas of each category are organized into the appropriate swim lane. Strategy Maps are especially beneficial when a company is looking to better their sales or reinforce internal processes. They allow improvements to be viewed from several different viewpoints, which assists in the decision process.
SWOT SWOT diagrams can be especially useful when trying to decide whether or not to embark on a certain venture by determining if the pros outweigh the cons. By clearly outlining all positives and negatives concerning the project, it will be easier to decide whether or not it is really worth it.

Diagrams of notable mention:

Flow Chart / org chart, Swimlane, Gantt, Strategy Map, Rich Picture, Decision, Network diagram ,Pyramid Chart

The ROI: I can't see it

So I have merely gone through and listed the tools you can use - where's the ROI you ask? Well its two fold: Firstly, we identified new ways you can express your processes or maybe this simply reminded you of the options and tools you can reach for while documenting your complex sleep inducing processes. Secondly, we helped your audience. If you begin to implement or increase your usage of diagramming techniques, your documentation will become easier to grasp, more enjoyable and, for those that skim through,  easier to pick out the key points.

With some luck, this illustrated documentation tools you are egger to try and as always….

Hope this has helped and not hindered!

-Project ROI

References:

I stole a lot from here -->

http://www.smartdraw.com/resources/glossary/strategy-maps/#/resources/glossary/Balanced-Scorecard

http://commons.wikimedia.org/wiki/General_diagram_types

eCrater: A Review for a Small Buisness

The OverviewI was recently asked to provide a review of eCrater, a free online store template that can be used to quickly setup a online store. If you haven't heard of eCrater.com - don't worry neither did I before I was ask for my thoughts on it.

eCrater provides a common and simple layout for offering products online. The site layout can be customized with a combination of templates (7 to choose from) and images. The images are to be provided by the store owner and can be used to represent the store logo, company name, products and categories (featured on the home site).  Additionally, eCrater also embeds its own advertising banners within the products page.

The Organization

A small tool supply company that sells products under 3 Brands. The challenges that faced were numerous as this is a small company that hosts its product information in many Excel spreadsheets - one sheet for each product and all its variations. I attempted to consolidate this product information with the goal of providing a functional example (will not take actual orders) of what they can do to quickly move to a web based order taking system.

The Process

The product catalog files had to be consolidated this involved a manual extraction, for each page of the catalog, of each product item entry. Secondly, for the purposes of eCrater’s bulk import, product images were stored to a publically accessible location which was added to the upload file. The product file was then consolidated to unique products by image which was done to ensure the file would be successfully uploaded when manually reviewed by eCrater for unique products. This consolidation resulted in 54 unique products- eCrater requires a minimum of 50 unique products for the import to be accepted. Finally, after consolidating to the unique products, a tabbed delimited file was created and uploaded to eCrater.com - it took 4 days to be manually processed by eCrater.

The Pains
The most frustrating experience in creating the site on eCrater was by far the Bulk List functionality. Creating a simple tab delimited text file was time consuming and uploading required several attempts. On the first attempt, I wanted to see what the site would look like with populated data. I quickly created a file for import through the eCrater "Add New Import" function of the "Bulk List/eBay Import" option. This quick test resulted in the file structure containing basic errors, such as missing the header and  formatting of quantity values and fatal errors such as length of the file ("Fatal error: Bulk file contains less than 50 products").  These errors prompted further investigation into the process which revealed several issues with the process:

1. Each product needs to be completely unique. eCrater does not provide functionality to offer varying sizes of the same product nor does it permit multiple entries of similar products to contain the same image. This is a severe limitation for the tool supply company offers numerous variations of a particular product.

2. Manual Review Process - Once the file is uploaded and approved by import process, a manual review process is triggered. This process took four (4) days to complete and with no notification, the uploaded products were offered online. The online forums also indicate that a site can also be deactivated without notice.
3. Although Categorization and nesting of categories is extremely simply and easily incorporated into the bulk import file, products cannot be listed under multiple  categories. 

The Gains
As a small business where funds and technological skill are not readily available, eCrater provides for a good start to developing a online presence. The promotion tools and guidance would be a extremely valuable feature for a company attempting to create an online presence for the first time. When a site is finally up and running, the benefits of using eCrater far outweigh the cons - the primary benefit is the speed at which I was able to create a functioning site - minutes. I was able to create a subdomain, high level categories and a small number of products in minutes.  

The ROI

Creating an ecommerce site on eCrater, although quick and feature rich, was too simple for a company with the need to list products with multiple specification variations as well as multiple product categories. While limitation of eCrater were reached during the sample deployment, the ease of use features, payment processing functionality and marketplace all provide significant benefit to the small business with extremely limited resources.

Hope this helps and not hinders!

-Project: ROI

The following is my approach and thoughts on the site.

AGILE! My old nemesis.

 

I LOATH AGILE DEVELOPMENT.

Ahhhhh... that felt good to get off my chest. To be honest, Agile development is a great idea. I don't hate it, just the way its implemented. It becomes an excuse for doing less 'fluff' and more coding.

 :| Oh no, this will end badly.

In one organization I witnessed the implementation of Agile methodologies with this kickoff:

 "Ok we're going to be doing Agile now. The good news is we have been doing it all along! Yay."

They were doing the bare minimum to get by on a large scale project and now they wanted to implement Agile. What they really wanted to do was to justify their 'effort' to the client and they did! They had some daily processes in place, team structures yet documentation of the system prevented knowledge transfer. We would see, and all to often, production systems being effected by updates that did not receive full testing and updates effecting other systems because dependencies were not documented. Changing their development methodology was not going to fix their problems, especially if the information needed is never recorded let alone access.

This is a prime example of why I loath AGILE - the implementation.

DO AS MUCH OF WHAT YOU CAN… to move the project forward

This usually doesn't mean comments, documentation or planning. When done right, progress can be made and quickly. The scrums allow for progress to be track, controlled and perhaps documented. Problems can be quickly resolved and a small team can accomplish amazing results. However; if you are thinking about implementing AGILE or any other development methodology you have to think to your self - what are we looking to get out of this, what's the ROI?

Development methodologies, and I am going to generalize, are a set of steps followed during development to produce a result. This result is not, in my opinion just the final output but the surrounding documentation that supports it. If there is a problem and the developer is MIA, where do you go? In my first development job, the methodology was developed in-house and was flexible. Depending on the size of the project, certain steps would be included (ie feasibility steps were omitted when changing report formatting)

If you can answer this, then you have a better chance at picking the solution/approach that best fits your organization. There are so many models to follow during the Software Development Lifecycle (SDLC) such as recursive, waterfall etc., that you should gather a good understating of each rather than implementing what's hot: AGILE.

The ROI

The benefit of using the AGILE methodology is primarily the speed of development. With clear objectives and a team leader that can stay focused on the target, the results will be shorter development time (cost savings) and concise documentation. This is key - clear goals that are not moving targets are great candidates for this approach. If you find that the goal shifts frequently, then you may have other project management issues to contend with in addition to development problems; however, this too can be resolved with AGILE - provided the team understands that with shifting goals the end may never be reached. The constant contact with the customer will provide for a deeper relationship and develop customer loyalty - provided the team leader can manage scope creep.

At a later date we will have to review AGILE and its components in more detail. For today - hopefully you now know what you're getting yourself into and why.

Hope this helps and not hinders, Enjoy!

DOCUMENTATION is for wimps!

Coders code, PM's write Diaries!

Within every major IT department, there really only two job functions: Coders and non-coders. The coders to which I am referring are those people who speak in binary, code in assembler, and haven't seen the sun since their first computer (aka Code Monkey). Then there is everyone else - you know - people. People who speak your language - english or better yet business, people who know technical details as well as the function of a balance sheet and people who can communicate.

WARNING: Graphic Images! This is an actual dramatization... of a coder writing documentation.

Verbose pseudo code

Communication is important. Correction: Communication is VERY important. Whether you are documenting a new application (preferably pre-development), meeting minutes or project status', communication is now at the core of the IT function. No longer is it adequate for coders to just code - they also need business knowledge and communication skills. Sure, a good coder might leave a few comments sprinkled throughout their code libraries, although greatly appreciated - it's not enough.

Now I have to admit - I was a code monkey in training. Yes, yes its true; however I managed to break free. As a junior coder I was stuck in a hobbit hole somewhere coding while the people around me conversed - then I discovered documentation (beam of light from the heavens and choir singing). There was a gleaming piece of hope that I followed out of my hole.

Sure the true IT grit lies with the coders (admins may argue), but you or your team can evolve to be the uber multi-lingual geek. A coder who not only writes code but communicates their intentions to the business and NO we are not writing Diaries and its not girly.  Documentation is like coding - actually think of it as "Verbose pseudo code" and the compiler is known as "Marketing".

Don't be a code monkey - document!

Writing documentation sucks - a lot. However, the benefit is that it communicates your ideas to your team, client and/or bosses. It helps you think through your approach, serves as a road map and simplifies the development process. Ever hear a coder say "Oh I must have overlooked that" in reference to a key issue created by the poorly documented change? Of course you have. With a little communication, the business need could have been outlined for the developer (not coder) and in turn, the approach could have been documented prior to development. The benefit of these steps are:

1. Business articulates their need

2. IT reveals the approach
3. Everyone agrees (scope)
4. Impact of proposed changes (scope creep) can be evaluated against project plan.
5. New team members can get up to speed quickly

In one office, I was replacing the code monkey who decided it was time to leave. I had less than 2 weeks to extract all the knowledge he had because once he left so did the documentation.  The real reason he was leaving? I think he realized he made a mess of the systems and could not remember what any of them did. For the next few months, I spent my time stumbling through the systems and trying to document what they actually did and in the event of a failure - I did this while debugging. Sure we made mistakes - but by the time we were done - the core systems were usable.

Ramble, Ramble - Now The ROI

Good documentation saves time, money, customers and sanity. Coders have a map to follow and what the system does is clear and available - You don't have to step though the code to figure out what it does or wait for the code monkey to return from vacation to point you in the right direction. Customers will benefit from the professionalism and the reduced errors due to forgotten specifications/functionality. Finally, when you stop shooting yourself in the foot, everybody wins!

Hope this helps and not hinders!

-Project: ROI

Links

89 BENEFITS of documentation <-- looks through - not sure there was too much documentation

Benefits of Good documentation

The Swelling Ground

POST it!

Just finished Groundswell (2008), a great book on social media by two Forrester research writers: Charlene Li and Josh Bernoff. In it they point out a lot of great ideas regarding social media, including P.O.S.T.  The examples in the book refer to large organizations; however, there is no reason a small business can't take advantage of the same tools. Actually, a lot of the approaches in the book are virtually free and free fits with most small business marketing budgets.

One of the concepts described in Groundswell is "POST". POST discusses social media approach and stands for: People, Objectives, Strategy and Technology:

People. Know your audience! figure out who you are trying to reach and get to know them. I don't mean invite them over for dinner but know what they are typically looking for - DEMOGRAPHICS! When you have them figured out then continue on with your strategy. Objectives. What are you trying to do? Seriously. Now that you know who your customers are, when you try to connect with them, what are you trying to get out of it and maybe more importantly, what are your customers going to get out of the interaction. You need to, in detail, determine how you will promote your message, listen to your customer's opinions (good or bad), and how you'll response to it. Strategy. Now armed with this information, how do you enact your objectives? You now know your customers, you're interacting with them and they with you. How do you continue with this exchange - long term. This needs to become a permanent relationship to foster an exchange of ideas. Technology. SOCIAL MEDIA - what are the tools you plan on using? you have choices - lots of them. Forums, wiki, blog, facebook, twitter, etc. With a overall view of POST, you will be able to make an informed decision as how to proceed. If you liked this, then Get the Book!

Hope this helped and not hindered!

-Project: ROI



Stuck in the Middleware with you.

 

ARGH - now what is middleware?

Relax. This one is easy - middleware is software that is placed between two systems (ie. in the middle).

Ok so what is it doing there? The simple answer is Middleware is facilitating. Take the following analogy:

You seat yourself, along with your friends/family at a table in a restaurant. Your goal is to get food from the kitchen onto your table. You achieve this objective by speaking with a waitress. Her name: Middleware. As a customer, you look to Middleware for information on kitchen contents, capabilities and specialties.  Middleware can speak customer (smiles and prompt service) and can also speak 'kitchen' (clear, concise and demanding). Middleware will go to the kitchen to convey your orders and return the result (your food) and to the correct recipient. Should you require more food, have a complaint or even a compliment, middleware can pass on your message - That’s her job. 

Software is very similar, you have two (2) disparate groups (Customer/Cook or ERP/CRM) that need to 'talk'. You need a translator, facilitator, you need middleware! Middleware will speak both languages and communicate those messages to the other party (check out my post: "Psst! I have something to share...EAI"). The messages can be between related or unrelated systems - all that matters is a need to share some information.

Give me some - I'm sold

Ok so where do you get it? The answer: it depends. There are a lot of third party vendors that offer various middleware solutions such as those offered by Microsoft ( BizTalk ), IBM and SAP. Let talk about BizTalk for a second, "BizTalk enables your organization to seamlessly integrate disparate systems and connect business partners ".  In english, here’s a picture:

What this is showing is the waitress/middleware as BizTalk Server and the customers as, for example, Inventory Application. The middleware communicates with the inventory app and passes on the request to the kitchen (ERP). Ultimately this communication results in fulfillment :D

To sum it up - middleware provides a common platform where messages can be exchanged between two systems as to share information that would not have otherwise been possible.

Hope this helps and not hinders, Enjoy!

Psst! I have something to share….EAI

When two people have to share information there is a set of steps that need to be followed. For one, there needs to be a message and preferably worth hearing. This message is then sent to a another person who listens, filters out noise and interprets the message - if necessary, a response is sent.  This is the basis for simple communication. We all do it - daily. For those of us that don't - there is a picture, the 'Shannon Diagram' or 'Schematic Diagram of a General Communication System'.  The interaction between complex enterprise systems are no more difficult to understand as a simple conversation between two people.

EAI = Enterprise Application Integration

Enterprise systems are no different then people - in the case of the IBM Watson computer, they are people too!  They want to talk. In order for them to talk, they need to share messages/information. This information needs to be cleansed (see scrubbing and de-dup below) , transmitted (ODBC, Web services, CSV, XML etc.) and received by the destination system.

Click here for more on Watson

Sound Simple? Well it is - almost...

From a security, content and technical aspect,  make sure all parties are on side with the transmission of data  as this is where the project difficulties usually lie. Complications in expectations can and will occur. As the project manager, you will need to identify all shareholders that 'own' the data and systems involved in the transmission. This will assist in mitigating any risk that your team(s) will rely on incorrect definitions or encounter roadblocks (ie Legal).  Another complication arises in complexity of the discussion between systems - will the communication between two systems be Unidirectional or Bidirectional (round-trip). The difference?

Unidirectional is like a dictator forcing its data onto the other system (easier).

Bidirectional - this is a conversation between two systems - issues such as timing (real-time, nightly, weekly etc) and data ownership come into play. Both systems will be required to import and transmit the required shared data in the same way (ODBC, Web services, CSV, XML etc.).

Spend some time and get this process right the first time! And for the love of <Insert Deity Here>  don't skimp on testing.

Scrubbing / data cleanse

Before you send a message, take the time to ensure it makes sense. This is why we 'scrub' data. Cleansing is referring to identifying crucial records/data, duplicates, merging records, updating key data, and resolving data issues. We clean it up so where ever we send it, the information will make sense. Don't kid yourself - if you are undertaking a data scrubbing exercise, it'll be a manual boring and grueling job that only those most familiar to the data can really do well. Sure you can get the contractor to write a query, perform magic/voodoo; however, the data will not be a complete, thorough and accurate unless you have the right people taking the time to cleanse (not purge) the data.

De-dup it

I hate the term - hate it. But. It is actually widely used so you'll need to be familiar - it just means de-duplicate or to remove duplicates. I prefer the term: singularity-ify (thank-you Star Trek :P )- ok so "de-dup" is better - for now.

Booyah - you're knees deep into a EAI discussion now!

Ok let's review - you've identified the Enterprise Applications that require Integration, the data to be shared and all the parties that could be effected. Next, the team identifies what is to be shared and how. This step will determine how much scrubbing, cleansing and de-duping is required. Finally, the process of communication between two systems will it be Unidirectional or Bidirectional (round-trip).

The Checklist

1. Is there a real need?
2. For whom (get the parties in at ground zero)
3. What is to be transmitted (be thorough)
4. How - think this through
5. Prep - clean up the data
6. TEST TEST TEST
7. TRAIN - give your team a fair chance
8. How did it go? (post-mortem)

Hope this helps and not hinders, Enjoy!

Creppy Scope

Do you know someone with a creepy looking scope?

In case you are unable to identify scope creep, I am including a crude mug shot of what to watch for. Primarily, changes to your calendar; however, that is not to say more work with no change to the calendar is not also scope creep - it is! Actually, lets start by saying that once the objectives and requirements have been identified and agreed to by all relevant parties - any changes to the requirements is scope creep.

  

There is nothing worse than a project with creepy looking scope.

Avoiding the coyote ugly scope creep - Ever agree to something only to want to cut off your arm the next day? Well that’s scope creep coyote ugly! Your job is not to agree to scope creep without consulting the <in booming voice> "Triple Constraint Matrix" <echo echo echo>.

The whosey whatsit?

The Triple constraint matrix contains 3 variables (Time, Scope, Cost) and is your guide to scope creep. No need to worry its incredibly easy to follow - the triangle shows that you cannot change one element without adjusting another. So if you have to make a change just use the formula below"

"With an change in __________, I will maintain ________ and adjust _________!"

So the next time your clients says "We need the deliverable sooner at the same price.", you can respond with:

"With an change in TIME, I will maintain COST and adjust SCOPE!"

With this statement, we can deliver on time, at the price specified, but certain items may not make the cut - in this phase. If the client is adamant that that nothing else change, you'll find that the project just got more difficult to complete on schedule and within budget. If you accept the challenge the client presents, beware that issues in the project will more than likely appear.

Hope this helps and not hinders, Enjoy!