Blog

Agile approaches and the risk Trade-off

Blog post
added by
Wiki Admin

We were discussing Good, Bad, and Ugly on Agile. As we were, we were able to appreciate many points on Why Agile? article on wunderkrautNot setting too narrow a goal on techwell.com as well as a slightly aligned and counter article on Fixed Price Contracts for Agile Teams

Here were some of our takeaways.

The Good – Agile helps reduce risk of not meeting project goals.

If the project goals are to stand up a new service, application, use case, workflow, visualization, data feed, or other very specific components, Agile will help you launch those speicifc components solving specific user stories within epic problems rapidly. You can also blend Agile development with lean to make sure you launch beta, soft, or early versions to a closed set of known users or under a brand to show to anyone. This can avoid embarassing deployments and also expose aspects missed – negative testing (think 5year old pounding on keyboard or tablet), security testing, load testing, or experience modeling. You have a better chance of this “Agile lean” blend to finding out early on the adoption and rollout issues. The Agile Lean approach allows you to move final decisions on features and form to when you have due diligence of mockups, prototypes, or initial deployments at smaller scales, which allows you learn are you go, and decide when you know, at least investment cost.

This AgileLean approach works for component or service architectures. Keep in mind, it does NOT work for legacy architectures where the architectures themselves are not flexible enough for agile development, refactoring, architecture, or deployment. Using Agile in these cases are actually HIGHER RISK as the learning curve discovers problems very late in the phase, and thus causes more problems, higher cost. So if you are doing system integration with new and legacy, balance where you can and cannot use AgileLean.

Given the focus is on the project goals, dont set the goal too narrow, and be prepared for your requirements to change, flux, and adjust as you learn and focus on achieving that goal.

The Bad – You will likely not hit the your defined project scope.

Some ask, is this bad? Was the initial project scope right anyhow? Were there too many features, functions that were on the nice-to-have list that snuck into the required for business? Sometimes Agile will help trim the fat and focus to make sure we do not shop hungry.

Then again, where it is bad, some of the initial scope desired was key, but turns out the architecture chosen and discovered through the learning curve led you down a wrong path, and there is a few re-starts that need to re-occure to introduce new patterns, components, operating concepts, etc. This could happen multiple times if the architecture reset is done with only the development and management project team. A way to avoid this is any re-architecture needs to involve the proper stake and stockholders governing and investing in the program. Whereas Agile tends to be responding to the functional manager, if the design, flow, and strategy needs to be re-set, then those questions need to go beyond the functional manager, and back to the right stakeholders.

The Ugly – Government Contracting is not ready for Agile… today

Consider if you do firm fixed price contracts, how you define deliverables up front. Articles like Fixed Price Contracts for Agile Teams give you ways to play the cards you are dealt and work within the Firm Fixed Price framework, but there is a reality. If the epics are in development, user stories unknown, specific components unknown, make sure the contracts are setup to define deliverables that show developing and deploying x # of 2 week sprints in desired environments with desired scope from clients that assumes these type of skills. Even that level of description may be complicated to reply to. How much level of effort per sprint? Are the technologies hardened or could new ones come about (Answer is the latter)? Are the sprints to productions, staging, or soft-launch? Agile development or Agile Design is VERY hard to do in fixed contracts. Legalities do tend to cause some hiccups.

Then again, the other options of T&M have their own problems of accountability, but that is a more mom and apple pie argument.

We are still seeing RFP and RFIs go out asking for the enchilada and waterfall. Its what the Contracting Officer space knows. “Systems” are being asked as the common jargon, but the layers of “services”, “components” are clearly being demarcated to help with agile bidding. This typically that does not bode well for Agile UNLESS if it prescribes system, it also “services” and “components” solution architecture principles that forces the responders to respond with an architecture that itself allows for Agile. You cannot do agile on traditional tightly coupled architectures. You end up just doing iterative instead at best which does have its differences

And somewhere in between, bidding as lowest price, technically acceptable is the WORST agile solution, as the only capability of doing that is responding to the technical specs, and not what is really needed – Agile-skilled, impassioned “Ninja” developers who can adapt to changing technologies. LPTA would bring in the Junior developer, and since a Senior developer has much increased output for Agile Development that goes live, and reduces the cost of the acceptance period as they understand how to design code for integration, negative, security, and load testing, and for the O&M teams to manage, deploy, and support.

So if you are pitching Agile, beware if the customer is saying great, now respond to that FFP or competing it LPTA.

Medieval Project Management is actually a real thing to learn about

Blog post
added by
Wiki Admin

Staffing solutions is a major part of project management. Internal staff, low-cost staff augmentation, consulting project teams, embedded consultants, employees other duties as assigned, employee working groups, employee standing teams, consulting advisors. All these solutions help address gaps in individual skillsets by bringing others strengths.

The reactions and solutions in “Handling delays on Internal Projects due to skill gaps” help address bringing in consultants and focus on the timing being right-sized and with very clear defined lines. This actually goes back a long ways, to the initial western world village-sized projects. Now urban center feats are well-documented large enterprise projects efforts and were done typically with a fair-amount of dictatorship. But agrarian or travel towns did not have such authority, resources. Smaller kingdoms completely relied on advancing barracks, granaries, resource production, city walls, and maintaining people in the kingdom to advance –both for the security of the city, but being honest, the advancement of the monarchy.

There are actually several books on “Medieval Project Management” (i.e. here) that goes into how kingdom projects were managed – both fair and beloved kingdoms and ruthless or poor kingdoms.

Here is an example, which illustrates one thing – not much has changed in the staff management aspects:

A well-liked king has a goal to build a moat and bigger drawbridge to allow both larger carts to come in and out of the town, while allowing for protection against marauders. The townspeople have never built this before and certainly not to this complexity. The king knows of another town where it has been done before and suggests to bring in this help.

The townspeople say “we can do it”. The king knows loyalty is a prime asset, and completing a project, with townspeople at work creates just that. The townspeople, unfortunately, struggle with designing to the new scale and has spent more than anticipated, and nothing is yet built nor designed to work.

The king, recalling loyalty is key, doubles-down, but attempts to buy back risk by saying he will bring an advisor in.  The townspeople once again say “we can do it ourselves”. The king takes this risk and approves the project without delay. Delays continue, and once again time and money from the coffers pass.

The king noting they are very far behind, and other towns now have competing sized bridges and moats, now says lets bring in an advisor and a designer who recently finished these projects, but you can still be proud by building the bridge. The townspeople say “we can do it, we just need more time, we almost have it figured out, we need more townspeople”. The king now irritated, knowing loyalty is a major asset, once again reluctantly delays, as now half the town is involved in the project.

Unfortunately, a year has gone by without a new bridge. The marketplace is stagnant, other towns are growing, jobs in the town are now stagnant, and the king knows he can wait no longer. Now, the townspeople are angry they are overworked as they have to work more to make enough.

The king final says, I have now paid the others to take over the project, we cannot wait any longer. The king could resort to heavy penalties, but with half the town, and buried deep, any swift hard actions could result in revolt. Instead, he issues a stern decree, citing their failure, and he has now turned the project over, and the costs are now quadrupled (original costs doubled by failure, plus a double-cost rush order from outsiders and the king must now provide extra protection and oversight for the outsiders to just get started)

The townspeople did not say “well, he gave us a chance” and we were gainfully employed. The townspeople were not thankful for the work on an incomplete job. Instead, the idea of a new marketplace is at an all-time low (though all other towns are flourishing with the new marketplace). The townspeople spread rumors of any sign of delays, weakness, or possible conspiracy or even sabotage. The king must spend time mending the townspeople’s now unruly position.

The project is finished, quadruple costs, double the time, and unfortunately, economically, the shift has occurred. The townspeople decide to uproot and go to the next town anyhow as they heard about how their marketplace is bustling with new jobs and goods as they were able to complete the new wider drawbridge that this king couldn’t and the kingdom goes into dark times trying to recover.

Not much has changed from medieval times in corporate cultures. Balancing the culture health of the company is a big deal. The perception that happy employees produce 1.5-5x as much as unhappy employs is slightly true. But it is not about happiness. Note the story talks about the townspeople wanting to accomplish a big project and would be proud, and the kingdom would expand, and townspeople would be loyal and thankful. Happiness was not in there.

But, the townspeople also had a lack of vision. The king gave a major contract to an untrained, demanding union with a sales pitch of the low price of loyalty, and technically we have done it before. Without a measuring device to objectively allow pulling the contract back, the contract modifications continued, and the king was now all-in.

The king can take the risk on such a contract award – The king did not ask for an initial task to prove their merit. The king did not treat the award of the project to his own people like the award of a performance-based contract to outsiders.

Conclusion: Any project you budget for, award it and set the measures for success whether it is done by your staff or outsider consulting team contract.

All projects require milestones (another medieval term continued from Roman times), clear objectives to guide quality levels and deliverables for scope and some semblance of budget and resource management (whether it is time and materials with a not to exceed, or fixed-time, fixed-price phases).

The similarities are the same – the project failure was not the townspeople. Just like the project success is on the king, or the executive, the decisions on project staffing are on the executive. Take that measured initial risk, but if metrics are showing clear, you need to adjust, using the agreed measure failure as the guidance to approve the switch.

Can a predictable supply chain for geospatial data be done

Blog post
added by
Wiki Admin

Creating Predictability in the Government’s Geospatial Data Supply Chain…

This article expands upon the presentation on What does geodata.gov mean to data.gov presented at the First International Open Government Data Conference in November 2010 and as well the GAO releases report on FGDC Role and Geospatial Information which emphasizes similar focus on getting the data right.

Would it be valuable to establish predictability in the government geospatial data supply chain? 

As examples, what if one could be guaranteed that every year or two the United States Census Bureau produced in cooperation with state and local authorities or that HHS produced a high quality updated county boundary dataset would produce a geocoded attributed list of all the hospitals in the country validated by the health care providers.  Of course it would be valuable and could provide the means to minimize redundant data purchasing, collection and processing.

If the answer is “of course”, then why haven’t we done so already? 

It is a simple concept, but one without an implementation strategy.  Twenty years after the establishment of Circular A-16 and FGDC metadata content standards, we are still looking at metadata from a dataset centric point of view -that is for “what has been” and not for “what will be”.  Knowing what is coming and when it is coming enables one to plan.

The model can be shifted to the “what will be” perspective, if we adopt a system’s driven data lifecycle perspective. Which would mean we look at Data Predictability and Crowdsourcing.

It may seem ironic, in the age of crowd sourcing, to argue for predictable data lifecycle releases of pedigreed information and seemingly deny the power of the crowd.  But the fact remains, the civilian government entities in the US systematically collect and produce untold volumes of geospatial information (raster, vector, geo-code able attributes) through many systems including earth observation systems, mission programs using human capital, business IT systems, regulatory mandates, funding processes and cooperative agreements between multiple agencies and all levels of government. The governments in the US are enormous geospatial data aggregators but much of this work is accomplished in systems that owners and operators view as special but not “spatial”.  

An artificial boundary or perception has been created that geospatial data is different than other types of data and by extension so are the supporting systems. 

There remain challenges with data resolution, geometry types and attribution etc., but more importantly there is a management challenge here.  All of these data aggregation systems have or could have a predictable data lifecycle accompanied by publishing schedules and processing authority metadata. Subsequently, the crowd and geospatial communities could use its digital muscle to complement these systems resources if that is their desire and all government programs would be informed by having predictable data resources.

What is required is communicating the system’s outputs, owner and timetables. 

Once a data baseline is established, the geospatial users and crowd could determine the most valuable content gaps and use their resources more effectively; in essence, creating an expanded and informed community. To date, looking for geospatial information is more akin to an archaeological discovery process than searching for a book at the library.

What to do?

Not to downplay the significance of the geospatial and subject matter experts publishing value added datasets and metadata into clearinghouses and catalogs,  but we would stand to gain much more by determining which finite number of systems aggregate and produce the geospatial data and creating a predictable publishing calendar. 

In the current environment of limited resources, Xentity seeks to support efforts such as the FGDC, data.gov, and other National Geospatial Data Assets and OMB to help shift the focus on these primary sources of information that enable the community of use and organize the community of supply. This model would include publishing milestones from both past and futures that could be used to evaluate mission and geospatial end user requirements, allow for crowd sourcing to contribute and simplify searching for quality data.

Our Change Services Concepts

Blog post
added by
Wiki Admin

Our Concepts and Approach starts with the executive sponsor. 

We want to connect the line of sight from drivers to goals through products and services, process, roles, systems of information and technology and down through the bottom line. We can start with a short rapid implementation planning workshop to validate, discover, level-set, educate, and start your transformation effort on the right foot. Or we can use ITIL continuous improvement approach as part of supporting your operations.

Our methodology and training focuses on transformation leadership that can help improve customer effectiveness and efficiency. We do this by proactively managing risk and delivering results through strong, facilitated execution or increase relevancy and economics of existing or new product lines and services.  In working with customers, Xentity provides integrated oversight of the parts that need to be connected, understood, and communicated prior to significant investment.  This approach enables Xentity to understand value opportunities and risk, determine mitigation strategies, and support customer awareness on how to realize recommendations.  Once decisions and investments have been made, Xentity utilizes strong communication and project management skills to facilitate change. The methodology work we developed has been recognized and adopted as Federal Government best practices by the U.S. OMB.

This approach helps design, execute, and showcase major change through proven methods. We approach information and technology change from within the mission out to the enterprise. This is different. And it has been an adopted concept and method by the Federal Government and has become popular in the commercial space. Take on the right amount of change, a focus area at a time. This is what we know. It is what we do and have been doing since 2001. 

Either as a team creating deliverables, embedded consultants, or staff augmentation, our transformation designers, architects, analysts managers, management consultants, and creatives specialize in change.

 Our transformation approach and experts will help you buy-back the risk.

  •  Upfront, we can help you design and architect your transformation concept of operations, develop the full architecture and requirements before you go to the street using our collaborative business transformation approach.
  • We can tactically engage to support and manage your project – either existing project and team back on track or new project and team going on right foot.
  • We then can design and execute your outreach efforts and even produce short movies to help you brag about your change.
  • And for program support, and continuous improvement, we can provide your high-tech, geospatial, and science operations, analysis, and management with true subject-matter familiarity and staffing solutions. 

 We want to connect the line of sight from drivers to goals through products and services, process, roles, systems of information and technology and down through the bottom line. We can start with a short rapid implementation planning workshop to validate, discover, level-set, educate, and start your transformation effort on the right foot. Or we can use ITIL continuous improvement approach as part of supporting your operations. Read more about our Services on how we can design change with you or augment your current architecture, management, and communication staffing needs.

Address gaps early on. Buy back the risk.  

  • Get the right definition and design for embracing the right innovation and disruption concepts.
  • Coordinate and integrate your change to mediate and anticipate risks and challenges. 
  • Recover from current project design and management issues. 
  • Showcase and engage your community with your new or changed solution the way it deserves. 
  • Bring on someone that can help you with this transformation lifecycle

Our Services:

  • Buy-Back Risk of your transformation failing
  • Improve transformation requirements and concepts
  • Set path for most successful project implementation
  • Focus on Information Lifecycle challenges
  • Address Solutions for Disruptions in tech, business, and cultural shifts
  • Increase the likelihood of achieving your metrics and goals
  • Help accelerate time-to-market, 
  • Increase quality and relevance of your change effort.
  • Can include training and workshop to transition approaches to keep focus on continuous improvement
  • Tell the world your transformation story!

If this story below is you, these are services you need

Information Technology used to be hidden in your organization. Likely for Financials and other enterprise resource management or MIS. Ran as a cost-center under the CFO or COO.  Now its core to your business. Workforce costs are being replaced on the delivery or customer service ends by internet provided capabilities. Sales force automation, marketing campaigning, devices, storefronts, support desks, mission critical services – you name it.

Moreso, Now, data is an asset and your business is done online or through B2B information exchange. Its in the boardroom to the factory floor to the customer interface. You need to manage the information supply chain, use for management decisions, analytics, and in many cases your business is completely reliant on information and technology as your service. 

So you invest capital funds or operation funds deferrals in projects, development, infrastructure, contracts, etc.. in hopes of gaining that competitive edge or cost savings. This introduces new ways of doing business. And Change. Which of course, no one likes change except the change visionary.

The canary in the cave signals start to come in. The project the costs keep creeping up. Requirements weren`t there. Traditional cost-center procurement and development models were used to bid or build. You created a business case, but most of the time its ignored. A plan is used as the law, instead of the guide, and was wrong as business agility and the technology offerings changed before you even started. And an architecture or operating concept is either non-existent, incomplete, or build on old patterns.

As a result, the outcomes are not there, and delays, over-runs, re-designs are bringing forward nightmare scenarios. It gets risky. Before you know it, project costs are beyond up, a new technology is out, outcomes are missed and you and your stakeholders and stockholders are very skeptical. Worse yet, public relations and internal chatter is causing a culture of loss confidence which may leak public forcing an premature launch.

Something has to give.

You are at risk of joining the statistic that only 25% of IT projects succeed, 25% fail, and rest are partial wins/losses (Source: KPMG). 

This is where we come in – either before the nightmare occurs, or in the midst. We can operate as a project team, embedded consultants, or SWAT team.