Ten Technological Concepts Compressing the Analytical Timeline

Today’s difficult economic climate continues to cause increased competition for all organizations. Shrinking budgets are placing government departments and agencies under more pressure to increase operating efficiencies and cost-effectiveness of programs and technologies. Across industry, fragile markets have caused organizations to consider the need for every project, person, and printer to reduce operating costs. In the non-profit sector, slimming funding streams have caused an increased pressure to demonstrate value through concrete, measurable results.

In order to stay competitive within their particular domains, markets, and user communities – and to ultimately achieve growth and sustainability in any economic climate – all organizations must find ways to increase operating efficiencies, eliminate programmatic redundancies, and produce measurable results. Lucky for these organizations, several technological concepts have emerged over the past decade which help support these practices. In that regard, the acknowledgement, understanding, and implementation of these concepts across organizational units, programs, and processes will compress the analytical timeline and allow organizations to learn, control, adapt, and anticipate over time.

Here’s a quick look at some of the technological concepts/trends that are compressing the analytical timeline, allowing organizations to act on insights more quickly, more effectively, and more accurately:

  1. Data Collection Mechanisms – It’s not just about collecting more data, although volume (in many cases) helps. It is about collecting more types of data (image, audio, video, open source media, social media) and collecting more tactical data. The growth of the mobile and tablet markets, the ease-of-use of such devices and their decreasing costs, and the expansion of mobile network infrastructure around the world are helping organizations collect more diverse, tactical, and (ultimately) valuable data.
  2. Data Cleansing/Processing – Rather than ignoring unstructured data, we are beginning to embrace it. Many COTS, GOTS, and even open source technologies exist that cleanse and process unstructured data to ensure it can be used to support relevant use cases. Where unstructured data was formerly omitted from the analytical landscape, these technologies are now bringing new value and context to insights and decisions. Within this I want to also add the data storage/warehousing and processing capabilities that support big data analytics and data mining, which provides a quicker means by which the vast amount of data can be combed for relevant patterns and insights.
  3. Logical Data Structures – It seems we are finally learning that a little thought and planning up front does wonders for the types of analysis needed to support operations research, performance measurement, marketing, and other organizational practices. By building logical data structures, we can quantify things otherwise unquantifiable and ultimately make timely, informed decisions otherwise made by intuition alone.
  4. Data Standards/Models – In conjunction with building supportive, internal data structures, we are beginning to understand how data models within domains, across communities of interest, and for specific problem sets can do wonders for our analytical practices. By developing and/or adopting a standard, we can bring consistency to these analytical practices over time, even through personnel changes. No more one-off studies/reports, but rather repeatable and communicable analysis.
  5. Data Source Registries/Catalogs – It is slowly being understood that ubiquitous access to raw data sets is far from a reality. However, organizations are beginning to realize that data source catalogs (registries) across organizational units and/or communities of interest is a step that can quickly facilitate more effective data sharing practices. Rather than focus on the exposure of raw data, the data source catalog first involves the exposure of data source metadata – information about the data, but not the data itself. This data sharing approach is more strongly rooted in trust and visibility and, ultimately, can provide a platform by which analysts can gain quicker access to more relevant data.
  6. Social Networks – The social network movement has done many things to compress the analytical timeline, to include, but not limited to: driving more collaboration and interaction between data owners, analysts, end users, and ordinary people; driving a new means by which more tactical data can be accessed and collected; and facilitating the development of new platforms, applications, and technologies to glean insights from data.
  7. Identity Management, Access Control, & Cyber Security – Knocking down stovepipes can support better access to data which in turn can support less time collecting data and more time analyzing it. However, stovepipes provide organizations with another layer of security to prevent data breaches. Despite this contradiction, better identity management, access control, and security technologies are being developed to maintain a high level of control while still ensuring users can more easily access data traditionally hidden within stovepipes. In turn, the time spent accessing and integrating data is decreased and individuals can spend more time analyzing disparate data and delivering quality insights.
  8. Cloud Computing – The movement of information systems and applications to the cloud is transforming the analyst from being a thick-client-loving info hog to being a platform-agnostic, collaborative participant. With more data and tools exposed to individuals, no longer constrained by a single hard drive or device, analysts can more effectively and efficiently access, collect, integrate, visualize, analyze, share, and report on data and insights.
  9. Network Infrastructure – The expansion of existing connected and wireless networks as well as the development of new, quicker, more accessible, and more secure networks will continue to compress the time it takes for analysts to provide valuable insights.
  10. Customizable & User-Defined Interactions – Allowing individuals to define how they wish to visualize, analyze, and interact with relevant data provides analysts with the ability to focus on developing solutions rather than setting up problems. The “user-defined” movement provides flexibility and adaptability to the individual and allows a wider set of individuals to become analysts by owning their own workspaces and interactions. It also provides an interactive medium through which results can be presented, making the reporting and dissemination process interactive rather than a drawn out one-way street.

I do want to note that this list is by no means comprehensive. Even more importantly, it only focuses on technological concepts and does not address the numerous cultural and political factors that affect the analytical timeline. Although technology shall continue to be a major focus area in supporting quicker and more effective analytical practices, it is the cultural and political aspects that will be more difficult to overcome and their interdependence on the technological aspects should never be overlooked.

Balanced, Contextual Approaches to Thought & Action

Whether it’s your professional or personal life, sports team, volunteer group, or dinner plate, humans tend to think big. We see ourselves as astronauts on the moon, living happily by the beach, winning the championship, eliminating poverty, and sitting in front of the most beautiful plate of oven-baked lasagna.

In such cases, our human instincts serve us well; thinking big provides the foundation from which our minds find motivation, our lives feel purposeful, and our networks and circles come together under common goals and desires. Thinking big is a critical aspect of maintaining a purposeful life, by seeing life as a journey and not as a big mess of disconnected days, actions, people, movements, and thoughts.

That being said, our goals, dreams, desires, and overall intrinsic value come not through thinking big, but by acting small. The actions we take at each step in life are the driving factors behind where we end up and the impact we make. Our actions give us shape, form, and direction to realize our big thoughts. Our actions carry us through each day to build a purposeful story.

But is this notion of “think big, act small” (TBAS) the optimal approach? Some considerations to make:

1. Flipping the Paradigm: TBAS vs TSAB Approaches

What happens if we flip this paradigm of thinking big and acting small (TBAS)? What if instead we focused on thinking small and acting big (TSAB)? How would our shape, form, and direction differ?

Thinking small may provide us with the ability to deal with manageable chunks, the ability to break down large problems into smaller intellectual divots that we fill through logic and reason. Inherently, thinking small allows us to make smaller decisions, minimize risk, and to tightly align plans with results.

On the other hand, acting big can provide great visibility, posture, control, and leadership. Sure the risks may be elevated, but so are the rewards. Despite human nature, it seems that taking a TSAB approach through life can surely provide the same foundation for success and happiness that a TBAS approach provides.

So when should we utilize a  TBAS approach and when should we utilize a TSAB approach?

2. Understanding Scope: Approaches for Individuals vs Groups

How do our approaches to thinking and acting change given the surrounding environment at any given time? Is one approach better for the professional setting? Is another better for the soccer field? How should our strategies differ when considering differing circumstances? Most importantly, does the presence of others directly influence the scope of our thinking, and if so, to what extent might this be within our control?

I find myself thinking big in the morning, thinking smaller throughout the day, then thinking big again at night. Both morning and night are when I see and am around the least amount of people, while during the day it’s a constant interaction of many different people through conversations, technology, and sense. So is the scope of my thoughts primarily dependent on the size of my immediate social environment?

My actions are tougher to characterize as the scope of them has no obvious correlation to any temporal component, physical surroundings, or social environment. So are actions less guided by our surroundings than our thoughts? How does the scope of our actions and/or the willingness to take big actions depend on the size of the acting body? Is the success rate higher for larger groups taking smaller actions, or smaller groups taking larger actions?

3. Independence: Decoupling Thoughts from Actions

The discussion of scope lends us the idea that thoughts and actions may be influenced by completely different elements, from the time of day to the size of our immediate social environment. So does it benefit us at any one time to decouple thoughts from actions, or is it in our best interest to bind the two so tightly that all our actions are driven by thought, and all our thoughts stem from actions? Is the strength of the bond unique for every individual, and again, is it within our control?

Concluding Thoughts

At the end of the day it is my belief that, given the events in our lives both within and beyond our control, we should be readied with TBAS and TSAB approaches, guided by an assumption that the strength of the bond between thoughts and actions as well as the scope of each is well within our control. Some days our best approach is to build visions and lend a hand, while other days require thoughtful prayers and leaps of faith. Realizing these differing approaches while beginning to analyze the interactions between thoughts and actions is critical to providing strategies for any situation. More importantly, it maximizes the chance for positive results and successful outcomes, for both the individual and the populations at large. Now that’s a pretty big thought.

Crema de Calabacín (Zucchini Soup)

Crema de Calabacín (Zucchini Soup)
By: Kevin & Kayla
Difficulty: Easy
Prep/Cook Time: 30-40 Min

It’s an authentic Spanish soup with fresh, summery flavor.

Ingredients
Zucchini
Potatoes (baking / all-purpose)
Onion (vidalia/sweet)
Corn (canned or cooked/grilled and cut off a cob)
Cream (light / reduced fat)
Butter (SmartBalance)
Black Pepper
Salt

Directions

  1. Melt butter in the bottom of a large pan and saute the zucchini and chopped/diced onion (med to med-high heat). Add salt & pepper as necessary.
  2. Peel, chop/cube, and boil the potatoes. Drain when done, saving some of the hot water.
  3. When the zucchini/onion is done, add most of it to a food processor with some of the cream (we had to do this in two batches due to the size of our food processor). Puree the mixture, slowly adding the cream to reach a soupy consistency. Add olive oil too if desired.
  4. Add the zucchini/onion puree, potatoes, and corn to a pan on low heat. Add salt and pepper to taste and if necessary, stir in some of the extra potato water to reach a desired consistency.
  5. Simmer and stir on low heat for at least 10 minutes or until the smell is too good to wait any longer (we tasted it several times).

Additional Notes

  • Less is more. We kept the seasoning to a minimum – the true flavor of the pureed zucchini and onion is perfect as is.
  • We saved some of the sauteed onion to add directly to the soup during the last step to add a bit more texture.
  • We tried a few bites with shredded sharp cheddar cheese on top and it was very good.
  • We paired ours with a salad of green leaf lettuce and fresh vegetables, washed down with some wine although some sangria blanca would probably be best!

World’s Greatest Potato Salad

World’s Greatest Potato Salad
By:
Kevin & Kayla
Difficulty:
Easy
Est Time:
30-40 Min

Ingredients
Red-Skin Potatoes
Scallions (Green Onions)
Cheddar Cheese
Egg (Hard Boiled)
Mayonnaise
Rice Vinegar
Spicy Mustard
Frank’s Red Hot Sauce (any hot sauce will do)
Garlic Powder
Mustard Seed
Sugar
Cumin
Paprika
Salt
Black Pepper

Directions
Boil the potatoes until a fork can go through them with relative ease. If you want to save time, microwave them. Boil the eggs until they are done. Make sure you put the eggs in the cold water before it boils so they don’t crack. They should take about 12-14 minutes once the water starts boiling. Chop the scallions and throw them in a big bowl. Add the spices and liquids. When the potatoes are done, let them cool in the fridge/freezer for 5-10 minutes before adding them to the bowl (make sure you keep the skins on). Add the mayo, cheddar cheese, and crumble the hard boiled egg. Chop and chunk the potatoes to the desired consistency/size. Mix well (but not too well that it becomes mush) and chill until it is fully cool (although some like it warm/hot – nothing wrong with that).

2011 MLB Baseball Season Predictions

Well, actually got them in on time this year! Here are my annual pinstriped-biased predictions for the 2011 MLB season… LET’S GO YANKEES!!!

AL East Final Standings
Boston Red Sox 100-62 (61.73%)
New York Yankees 97-65 (59.88%)
Toronto Blue Jays 82-80 (50.62%)
Baltimore Orioles 78-84 (48.15%)
Tampa Bay Rays 76-86 (46.91%)

Post-Season Predictions
AL East: Red Sox
AL Central: Twins
AL West: Rangers
AL Wild Card: Yankees

NL East: Phillies
NL Central: Reds
NL West: Giants
NL Wild Card: Brewers

ALCS: Yankees over Red Sox
NLCS: Phillies over Reds

World Series: Yankees over Phillies in 7

Best of luck to Don Mattingly in his first year coaching the Dodgers!

Project Management Body of Knowledge (PMBOK) Notes – Project Life Cycle and Organization (Chapter 2)

Project Management Body of Knowledge (PMBOK) Guide 4th Edition
Chapter 2 – Project Life Cycle and Organization

Core Definitions

  • Project Life Cycle: A collection of generally sequential and sometimes overlapping project phases whose name and number are determined by the management and control needs of the organization or organizations involved in the project, the nature of the project itself, and its area of application. The project life cycle provides the basic framework for managing a project, regardless of the specific work involved.
  • Project Phases: Divisions within a project where extra control is needed to effectively manage the completion of a major deliverable. Project phases are typically completed sequentially, but can overlap in some situations.
  • Stakeholders: Persons or organizations (e.g. customers, sponsors, the performing organization, the public) who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project. Stakeholders also may exert influence over the project, its deliverables, and the project team members.
  • Organizational Process Assets: These include any or all process related assets, from any or all of the organizations involved in the project that can be used to influence the project’s success. Organizational process assets can be categorized as either processes and procedures (e.g. SOPs, guidelines, templates) or corporate knowledge base (e.g. measurement databases, project files, lessons learned, configuration management databases, issue management databases, financial databases).


General Notes

  • (2.0) It is important to remember that projects and project management take place in an environment that is broader than that of the project itself.
  • (2.1) Every project has a definite start and a definite end.
  • (2.1.1) Generic life cycle structure: starting the project, organizing and preparing, carrying out the project work, closing the project.
  • (2.1.1) Stakeholder influence, risk, uncertainty, and ability to influence the final characteristics of any/all outputs are high while cost and staffing levels are low at the beginning of the project life cycle.
  • (2.1.2) Project life cycles occur in one or more phases of a product life cycle, and the two can be very much intertwined.
  • (2.1.3.2) The three basic types of phase-to-phase relationships are: sequential, overlapping, and iterative.
  • (2.2) Operations work supports the business environment where projects are executed. As a result, there is generally a significant amount of interaction between operations departments and a project team as they work together to achieve project goals.
  • (2.3) Common stakeholders include: customers/users, sponsors, portfolio managers, program managers, the project management office (PMO), project managers, project team, functional managers, operations management, and business partners.

National Information Exchange Model (NIEM) Practical Implementer’s Course Notes – XML Conceptual Review (Lesson 2)

NIEM Practical Implementer’s Course
Lesson 2 – XML Conceptual Review

Core Definitions

  • Elements: The tags that exist within an XML document, collectively termed the “markup”. Types of elements include root, parent, and child.
  • Attributes: Part(s) of an XML element that provide(s) additional information about that element. Attributes are defined and written as a name/value pair (e.g. name=”value” ).
  • Instance: A document containing XML tags and content that results from use of XML schema rules.
  • Well-Formed Instance: An XML instance is “well-formed” if it uses the correct syntax and structure as defined by XML standard(s) being used and meets the minimum criteria for XML parsers to read the document.

General Notes

  • Rules/Guidelines for XML Elements
    • Can contain letters, numbers, and other characters.
    • Must not start with number or punctuation.
    • Must not start with xml, XML, or Xml.
    • Cannot contain spaces.
    • Should be descriptive to contained information.
    • Avoid dashes, colons, and periods (allowed, but usually are reserved for namespaces).
    • Avoid non-English letters/characters (allowed, but may not always be supported).
  • XML Prolog & Processing Instructions
    • Prolog specifies the version and the character encoding used for the XML instance and should always come first in every document.
    • Processing instructions are used to associate presentation and/or transformation files with the data.
  • XML Comments
    • Start with “<!– ” and end with ” –>”
    • Can include linebreaks.

 

Note: Information is being shared under the Creative Commons Attribution-ShareAlike 2.0 (CC BY-SA) license. Original content was created by NIEM course instructors Jenness, Owen, and Carlson.

National Information Exchange Model (NIEM) Practical Implementer’s Course Notes – Anatomy of an XML Exchange (Lesson 1)

NIEM Practical Implementer’s Course
Lesson 1 – Anatomy of an XML Exchange

Core Definitions

  • XML: eXtensible Mark‐up Language used to define and serialize data as well as define schemas, transformation rules, web services and visual presentation.
  • Message: One or more XML documents containing the data to be shared.
  • Publisher: An entity / software program that initiates a “One Way” exchange.
  • Subscriber: An entity / software program that receives messages in a “One Way” exchange.
  • Requestor: An entity / software program that initiates a “Two Way” exchange.
  • Responder: An entity / software program that receives “Request Messages” and returns “Response Messages” in a “Two Way” exchange.
  • Web Service: A type of program that allows a remote system (client) to interact with a program on a local system (server) using XML messages.
  • XML Document (.xml): A file that contains actual data and conforms to the rules of XML syntax (also known as an “Instance Document”).
  • XML Schema Document (.xsd): A set of rules to which an XML document must conform in order to be considered “valid”.
  • Web Service Description Language (.wsdl): Pronounced “wiz‐dull”, a document (containing XML) that describes the functionality of a Web Service (like a “Service Contract”).
  • XML Stylesheet (.xsl): An XML document that describes how XML data should be visually rendered.
  • XML Stylesheet Transformation (.xslt): An XML document that defines the rules by which a file defined by one schema is transformed (mapped) to a file defined by another schema.

General Notes

  • One-Way (Two-Party) Exchange Pattern (Publish/Subscribe)
    • Messages are pushed by a publisher directly to oneor more subscribers
    • Messages can be transactional or batch
    • Messages are transport neutral (web service, FTP, email, etc.)
    • Messages are essentially “fired and forgotten”
    • Pattern is very scalable as publisher is insulated from diverse subscriber interfaces
  • Two-Way Exchange Pattern (Request/Response)
    • Requestor sends an XML message requesting specific information
    • Responder replies with an XML message containing the requested information
    • Typically implemented via web services
    • Response is typically synchronous (occurs at about the same time)
  • Federated Query
    • Single request message may yield numerous response messages
    • Not all respondents may have data for every request
    • Typically built using a “Message Broker” device, insulating requestor
    • Message Broker aggregates multiple responses to requestor

 

Note: Information is being shared under the Creative Commons Attribution-ShareAlike 2.0 (CC BY-SA) license. Original content was created by NIEM course instructors Jenness, Owen, and Carlson.

Project Management Body of Knowledge (PMBOK) Notes – Introduction (Chapter 1)

Project Management Body of Knowledge (PMBOK) Guide 4th Edition
Chapter 1 – Introduction

Core Definitions

  • Project: A temporary endeavor undertaken to create a unique product, service, or result. Projects, within programs or portfolios, are a means of achieving organizational goals and objectives, often in the context of a strategic plan.
  • Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet project requirements.
  • Project Management Office (PMO): An organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project.
  • Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Projects within a program are related through the common outcome or collective capability.
  • Program Management: The centralized coordinated management of a program to achieve the program’s strategic objectives and benefits. Program management focuses on project interdependencies and helps determine the optimal approach for managing them.
  • Portfolio: A collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives.
  • Portfolio Management: The centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs, and other related work, to achieve specific strategic business objectives.
  • Operations: Permanent endeavors that produce repetitive outputs, with resources assigned to do basically the same set of tasks according to the standards institutionalized in a product life cycle.
  • Enterprise Environmental Factors: Both internal and external environmental factors that surround or influence a project’s success, to include, but not limited to: organizational culture, government/industry standards, infrastructure, existing human resources, personnel administration, marketplace conditions, stakeholder risk tolerances, political climate, and PM information systems.

General Notes

  • (1.2) Projects can have social, economic, and environmental impacts that far outlast the projects themselves.
  • (1.5) Projects require project management while operations require business process management (BPM) or operations management.
  • (1.6) Effective project management requires that the project manager (PM) possesses the following characteristics:
    • Knowledge: What the PM knows about project management
    • Performance: What the PM can do when applying project management knowledge
    • Personal: Behavior, attitude, leadership, balance and other core characteristics of the PM
  • (1.8) Enterprise environmental factors are considered inputs to most planning processes.