Xentity has been awarded a 5 year IDIQ for providing national data and geospatial support services to the U.S. Forest […]
We were discussing Good, Bad, and Ugly on Agile. As we were, we were able to appreciate many points on Why Agile? article on wunderkraut, Not 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.
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.
Xentity was recognized on CIO Review list for “20 Most Promising Government Technology Solution and Consulting Providers 2013” list.
With the advent of internet technologies, there has been a change in the landscape of business processes related to the Federal Government system. But the change hasn’t been easy as it requires constant dedication to move the entire workforce from traditional systems, and getting them to seamlessly adapt to the modern systems. This transition also includes the role of technology consulting providers, whose sole responsibility is to provide a wide spectrum of services in order to help the federal agencies to cope with the changes, in the best possible manner.
As customers and business partners increasingly demand greater empowerment, it is imminent for government companies to seek for improved interactions and relationships in their entire business ecosystems, by enhancing software capabilities for collaboration, gaining deeper customer and market insight and improving process management.
In the last few months, we have looked at hundreds of solution providers and consulting companies, and shortlisted the ones that are at the forefront of tackling challenges related to government industry.
In our selection we looked at the vendor’s capability to fulfill the needs of government companies through the supply of a variety of services that support core business processes of all government verticals, including innovation areas related to advanced technologies and smart customer management. We also looked at the service providers’ capabilities related to the deployment of cloud, Big Data and analytics, mobility, and social media in the specific context of the government business.
We also evaluated the vendors support for government bridging the gap between IT and Operations Technology. We present to you, CIOReview’s 20 Most Promising Government Technology Solution and Consulting Providers 2013.
CIO Review Magazine Full Article on Xentity:
Xentity Corporation: Rapidly Designing The Needed Change In Cost-Cutting Times
By Benita M
Friday, December 6, 2013
“We always try to believe that leaders want to execute positive change and can overcome the broken system. We are just that naïve,” says Matt Tricomi, Founder of Xentity Corporation in Golden, CO, named for “change your entity” which started on this premise just after 9/11 in 2001.“This desire started in 1999. I was lucky enough to be solution architect on the award winning re-architecture of united.com. It was a major revenue shift from paper to e-ticket, but the rollout included introducing kiosks to airports. Now that was both simple and impactful”. Xentity found their niche in providing these types of transformation in information lifecycle solutions. Xentity started slow, first, in providing embedded CIO and Chief Architect leadership for medium to large commercial organizations.
Xentity progressed, in 2003, into supporting Federal Government and soon thereafter International to help IT move from the 40-year old cost center model to where the commercial world had successfully transitioned – to a service center. “Our first Federal engagement was serendipitous. Our staff was core support on the Department of the Interior (DOI) Enterprise Architecture team”, Matt recalls on how the program went from “worst to first” after over $65 million in cuts. “We wanted to help turn architecture on its head by focusing on business areas, mission, or segments at a time, rather than attack the entire enterprise from an IT first perspective.” The business transformation approach developed ultimately resulted in being adopted as the centerpiece or core to the OMB Federal Segment Architecture Methodology (FSAM) in 2008.
Xentity focuses on the rapid and strategic design, planning and transformation outreach portion of the technology investment in programs or CIO services. This upfront portion is generally 5 to 10 percent of overall IT spending. Xentity helps address the near-term cost-cutting need while introducing the right multi-year operating concepts and shifts which take advantage of disruptions like Geospatial, Cloud, Big Data, Data Supply Chain, Visualization, and Knowledge Transfer. Xentity helped data.gov overcome eighty percent in budget cut this way. “Healthcare.gov is an unfortunate classic example. If acquisition teams had access to experts to help register risks early on, the procurement could have increased the technically acceptable threshold for success.”
One success story of Xentity is at United States Geological Survey (USGS). “After completing the DOI Geospatial Services Blueprint, one of several, the first program to be addressed was the largest: USGS National Mapping Program.” This very respected and proud 125-year old program had just been through major reductions in force, and was just trying to catch its breath. “The nation needs this program. The blueprint cited studies in which spending $1 on common “geo” data can spur $8 to $16 in economic development. Google Maps is one of thousands which use this data.” The challenge was to transition a paper map production program to be a data product and delivery services provider. “The effort affected program planning, data lifecycle, new delivery and service models, and road-mapping the technology and human resource plan. We did architecture, PMO, governance, planning, BPR, branding, etc.” Xentity, with its respected TV production capability, even supported high-gloss video production to deal with travel reduction and support communicating the program value and changes with partners and the new administration. This is definitely different than most technology firms. The National Map got back on the radar, increased usage significantly, and is expanding into more needed open data.
Presently, Xentity is a certified 8(a) small disadvantaged business with multiple GSA Schedules and GWACs (Government Wide Acquisition Contracts). Xentity invested heavily in Federal Business management. Part of providing innovative, pragmatic, and rapid architecture and embedding talent is being able to respond quickly with compliant business management vehicles. Xentity is constantly seeking out the passionate CIOs, Program Directors, Architects, and Managers looking at transformation in this cost-cutting environment. “Sequester, Fiscal Cliff, debt ceiling, continuing resolutions–it’s all tying the hands of the executives who can look at best six months out. They don’t have the time to both re-budget and rapidly design multi-year scenarios to out-year performance drivers and options let alone staff up to speed on the latest disruptions or right innovation. That is where we come in. We start small or as fast or slow as the executive wants or believes their organization can absorb and progress.”
IT Procurement as been a hot button issue as one of the largest civilian IT projects – DoD IT-sized in a way – was “bungled” in almost every phase: Cost went 6x original bid, architecture was overly complicated, no system integration concept, no end to end software or data lifecycle management end, and no quality acceptance procedures, criteria, incentive or the like.
We all know some or all those problems. But as the FCW article cites: “Bungled launches didn’t start with HealthCare.gov.” Its everywhere. Its government, commercial, non-profit, everywhere.
Of course, at Xentity we are biased – we believe in take your medicine now approach – design upfront, register and buy back the risks, and then move into agile design, rapid development, and iterative launch as relevancy and the market allows.
FCW notes there is “considerable agreement on how to go about overhauling the procurement system…” but they have some consensus on 5 key actions:
1. Do a better job on defining desired outcomes upfront
2. Improve the training options for the federal acquisition workforce to put them on an even footing with vendors
3. Give agency CIOs more budget authority
4. Avoid lowest price, technically acceptable contracts on large innovation-heavy projects.
5. Use agile development strategically and mainly when a project does not require a log of interaction with legacy systems.
To too our own horn, these are many of the fundamental goals that Xentity staff and solution focuses on. In reply to those five items:
1. This is our main emphasis on the design the concept of operations, and requirements for the SOW, and registering the risks and knowing them ahead before procurement. Still allow vendors the flexibility for logical and technical design, but know upfront the various concepts that may come back and know how to score them
2. our fedbiz.xentity.com business management specialists service integrated with our architecture practice allows us to help bring contracting and procurement specialization into helping understand how vendors who may respond based on market analysi results will respond to certain requirements or solicitation frameworks
3. We are setup to help advise CIOs on enterprise portfolio, architecture, capital planning, and segment adoption of CIO services and solutions
4. We agree that the LPTA method does not work for acquiring design, planning, creative, and solution management services. LPTA beltway experts tend to game the systems by replying to architect positions with application developer rates for architects on initial task order and techincally it is acceptable, and the rates are 30% better. But its a lot like asking a cook, “can you farm?” Technically, the cook probably could, but wouldnt you want someone familiar with the subject matter expertise of agriculture economics, farming lifecycles, key risk and success factors or someone who knows food. The solution ends up costing more as MODS occur, the app developer gets replaced, and government pays the cost for missing deadlines and scope creep.
5. This is a biggie! Marketing hyped up Agile as the “it slices, it dices, it julienne’s!”. It is great for new transaction systems on abstracted solutions. It can be good for some feed ETL or integration. But, when you have an immovable object, it doesnt matter how agile you are. In those cases, you need to conduct architecture design, concept of operation alternative analysis, business case evalution, requirements definition, and register and buy back risk.