Subscribe: The Confluent Forms blog
http://blog.confluentforms.com/feeds/posts/default/-/contract%20negotiations?alt=rss
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
contract  information  innovation  mediation  module  process  project  rfp  site  solution  solutions  technical  time  vendors 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: The Confluent Forms blog

Confluent Forms Web Design & Digital Strategy



Confluent Forms LLC, located in Easthampton MA, is a boutique branding, graphic design, web design, web development, Blogger development, and PHP/MySQL application development firm providing services to customers from the Fortune 100 to local non-profit o



Last Build Date: Wed, 21 Feb 2018 19:40:37 +0000

 



Technical Mediation: helping resolve technology disputes

Tue, 13 Aug 2013 13:01:00 +0000

Disputes are common over technologyThe project was grinding to a halt.Nobody wanted to lose developer X, not because he was especially friendly with anyone else on the team, but he had specific knowledge which, at the time, was deemed irreplaceable. Additionally, the organization was growing much faster than X was able to keep up. For a long time X was the entirety of the technical department of this small organization, now they were bringing in an outside consultancy to perform was was previously his sole domain. Worse, without the full cooperation of X the project was running into systems difficulties. This project had reached an impasse, no appeals from authority had been able to get things moving again. The ultimate sanction was unavailable against X and all the parties knew it. It was time for an attempt at an alternative strategy to solve this problem. It was time for technology mediation.Mediation is a process of dispute resolution which facilitates conflicted parties towards a negotiated settlement of their issues. The mediator uses a developed understanding of dispute resolution techniques in attempts to bring the parties to a joint solution. Mediation is not arbitration; in an arbitration the parties present their cases to a third party for a decision to be rendered. (Not seen as a realistic possibility in the situation above.) The mediator differs from an arbitrator in that they have no authority to settle the dispute. In a mediation the goal is to have the parties present their positions to each other, then work on solutions with the mediator acting as a facilitator for those discussions.In areas where disputes may lead to the emotional, financial and time cost of court litigation, mediation provides a faster, and cost-effective attempt at a solution. With a judge or arbitrator the solutions are imposed upon litigants; in mediation the solutions are mutually agreed upon and therefore do not feel imposed but rather accepted. This can lead to a greater willingness to cooperate in the solution's success. Mediation is not limited to legal disputes, but is applicable in areas of personal and business life. Technical mediation is the application of domain specific knowledge to bring a richness of depth to the mediation process (in our case IT/software engineering/web development). We are able to use our technical expertise to provide a relevant, technical, contextual layer to the mediation. Specific technical concepts (which may prove meaningless to the inexperienced) are used in getting to the heart of the matter. Why should you mediate in technical disputes In the disputes we mediate there is rarely a straightforward legal option for remedy. Team-based disagreement is usually arbitrated by a project manager or other immediate superior. It is important in technical disputes to try and allow those with the expertise to discover their own solutions. Pushing agendas from the top down rarely results in positive outcome. This is especially true when those pushing the contrived solution are perceived as having a less-than-complete understanding of the technical issues. Moreover, unlike civil matters or legal disputes, there is no "authority" over the technical matters. There are authorities over the individuals, but not over their deep-rooted concepts of what constitutes the most correct approach to any individual problem. There are usually strong opinions about how-things-should-be and generally accepted best practices; rarely do all teams agree on the one true way. Imposing technical authority because of corporate authority is not the best pathway to solution (nor always the most expedient). Whereas two parties may be in dispute, a third party "authority" may have a completely differing set of views, resulting not in a solution, but rather further disharmony! Understandings in a technical mediation It is important to understand in the technical culture your value be perceived in terms of the depth of your knowledge of the subject at hand. Placing oneself in-between knowledgeable parties witho[...]



The Module Mindset: you won't always get what you want

Mon, 22 Jul 2013 14:44:00 +0000

Modular thinking may make you too rigid.Content management frameworks (CMF) such as Drupal, Joomla, Wordpress and others enable site owners to build their websites while having a wide array of functionality available to them in the form of reusable code components. These modules, plug-ins, extensions, etc. are the building blocks that can help you manage specific types of content, add in extensive functionality, or bring special effects into your site.In these frameworks, modules are published in a way that gives other users of the same CMF the ability to reuse them in other installations. The flexibility of this module-based approach is that it extends the functionality of a CMF towards your intended purposes, while keeping the base system generic enough that users with distinctly different purposes are free to follow the same process towards their own ends. An added bonus is that in almost every case you may do this for little financial outlay as most of these components are made available free of charge. A powerful paradigm, however, module use, although free, is not entirely without costWhen you are using modules developed for other sites you are generally in a favorable situation. Someone else had a need, they had a module created to fulfill that need, they published it, gratis, and you get to benefit from their development time. In major CMFs there are modules for almost all needs. As you work more and more with other people's modules you begin to develop a module mindset: "this does just about what I want, and it doesn't cost anything, therefore this is good enough."Over time, this leads to an almost unconscious thought process comparing needs vs. what already exists in that solution space. Eventually it becomes easier to justify the adaption of exact needs to fit the existing solution (instead of a solution to fit the needs). This is an implicit application of the Ninety-ninety rule : the disproportionate amount of time it takes to accomplish the final details of a software solution. If someone has already gotten you 90% of the way there, isn't it better to adapt to the existing solution than to put forth full effort for a unique solution? For example:A customer hires a software solutions firm looking for answers to their problems. More often then not software solutions are being written for the web, and these content management frameworks have become a popular platform for this type of work. The customer generally does not care much about the technical implementation as the solution, they care about the technical implementation of the solution. What is used to make the features work is not nearly as important as the requested features working, and working as expected. This is where we see the most room for misunderstanding in projectsThe developer comes in with the module mindset; the customer wants their functional needs met. The developer and the customer begin talking past each other from the outset, but believing they have an understanding. "There is module that does that" takes two meanings when in effect there is a module that does almost that. The module mindset begins to discount functionality in favor of availability almost immediately. The customer, in the dark about the implementation details, believes that they have lucked into a solution: exactly what they want and already built. The developer is applying with own value system: it does 90% of what you needed, plus a bunch of other stuff you may need someday and is free... fortune smiles on us both! There seems to be an implicit appreciation of the Ninety-ninety rule especially around module based software systems. Pre-developed software is always a tempting value proposition, even if there are required tradeoffs to make it fit. Sometimes it is easier to shave the square peg to fit it into round hole. Developers should understand that their customers may not understand this as intuitively, if at all. They come into the project with a set of requirements, and expect that list to be fully met, no matter how [...]



Our EU Innovation delegation visit to Washington

Wed, 14 Mar 2012 13:40:00 +0000

In January, I (David) was invited to Washington DC to meet with the UK's Technology Strategy Board and a delegation of EU member states at the British Embassy. The focus of their meeting: striving to improve innovation support in Europe for Small and Medium-sized businesses. In particular they were seeking out best practices in innovation, and regarding us, innovation in procurement. The group included representatives from six European innovation agencies: Enterprise Ireland (Ireland), FFG (Austria), Agentschap (Netherlands), Tekes (Finland), Technology Strategy Board (UK) and VINNOVA (Sweden). You can read the first report here.Why were we invited to meet with this esteemed group from across the pond? It seems that the RFP Database had caught their attention. Our site's ability to harness the collective efforts of over 100,000 registered users to create a dynamic information gathering and information providing portal, within the procurement space, was something they wanted to learn more about. They wanted to know more about how the system operated, what we've learned from it in terms of what has worked and what hasn't worked, and what effects it has had on both the issuers of RFPs found in our system as well as the vendors that download the RFPs. It was a pleasure meeting with such an interesting group and getting a chance to discuss our site with them, but also perhaps have some impact on their own project(s).During the course of the meeting one topic kept coming back: how can government organizations encourage innovation in small and medium sized businesses?The typical way that bureaucrats respond to this question is by simply giving money away through "innovation grants", which can be found through Grants.gov, and totaling approximately $500 billion in annual awards.I think we can do better. I believe that governments of all sizes (federal, state and local) can best encourage innovation by demanding innovation in their purchasing.Government spending in 2010 totaled approximately $5.8 trillion, or ~12x the amount awarded through grants. The vast majority of that money is spent purchasing products and services, primarily with the goal of procuring a solution that will accomplish the task while costing the least. Check the requirement boxes, submit a fixed or hourly rate that is $1 less than your competitor, and you have a race to the bottom of the barrel. There's a great acronym for this: TALP (Technically Acceptable, Lowest Price).The only thing "innovative" about this is figuring out how low you can go with your pricing or how you can outsource more of your work in order to lower your pricing even more. This often doesn't encourage innovation, but instead encourages shipping work overseas, which frequently leads to a lower quality deliverable.In the interest of pitching an idea (and not simply complaining), I've written out the following process; the goals of the process are to a) lessen the amount of paperwork and non-billable time investment in order to continually bid on vague RFPs, b) reduce the barriers for entry (liability insurance, proof of, etc.), c) bring outside experts in to the procurement process in order to encourage innovative solutions.Open Innovation Sourcing modelPercentage of contracts identified or targeted through open voting as "ripe" for innovationAgency defines the problem(s) and goal(s)Agency issues a RFQ, selects 3-5 vendors to become collaborators based on their project pitch and examples of innovative solutions to related problems (a stipend position). At least one vendor must be new to government procurement.Each collaborator is tasked with participation in creative sessions to create an innovation solution to the problem and define the solution. Solutions are peer critiqued with multiple rounds of revisions, then graded by the procurement officer on projected savings (both short and long term), force multiplying affect, and support for small/medium sized businessesBased on the definition, a RF[...]



How to write Request for Proposals (RFP)

Fri, 19 Jun 2009 17:01:00 +0000

We believe strongly in Requests for Proposals (RFPs) as a tool for companies to find the best products and services at competitive prices, but also as an evaluation method for finding that elusive "best fit". However, too often the RFP process is run by people who have never experienced the process before, either from the issuer or vendor side, and essentially don't know what to say or what to ask. So we've broken it down into 6 steps to writing a better RFP.How to write a good RFP:Step 1: Do your research and define what you are seekingStep 2: Define your distribution strategy and information publication methodsStep 3: Provide the information necessary to a vendor to give the best quote possibleStep 4: Create a reasonable timelineStep 5: Identify the information you need from the vendor and the proposal formatStep 6: Determine your evaluation criteriaOur goal in this article is give you the basics that you might need to create your own RFP and run a RFP process without too much frustration. As an example we're going to use a small website redesign project (because that's what we do), but we hope you'll be able to extract the concepts you need for your own project. You can find lots of sample RFPs to use as research, perhaps even as a starter template, by going to the RFP Database.(P.S. if you meant to find an article on writing proposals instead of writing a Request for Proposals, please go here. If you'd prefer to not drive your respondents to drinking, please visit our RFP Drinking Game)Contact us for RFP consulting help!Step 1: do your research and define what you are seekingDon't jump into writing the RFP without doing your own internal homework. After receiving your RFP vendors will be beating down your door with dozens of questions; you're not going to want to be scrambling to find out answers which could then derail your timeline (more on that later). Defining your project as best you can will enable you to pass that information on to potential vendors, but also receive proposals that are tailored to your needs (pricing and project plans) by vendors who understand the project they are bidding on.Example: you want a website redesign Do you have existing brand material that will be used in the design or does that need to be created? Do you have the content for your new site written, or will that need to be created by the vendor or through a collaborative process? Do you envision this as a 5 page website or a large, 100+ page website? Who will be handling upkeep of the site, hosting, etc.? Do you need a Content Management System for maintaining the site and keeping it up to date or do you think it's going to stay fairly static? Are there any interactive pieces you need in the site or specific functionalities that will need to be implemented? Does the website need to interact with any database or 3rd party software?This is by no means an exhaustive list of the types of questions that vendors will be asking you. The more you know about your project, the better the answers you'll be able to give to guide the vendors into great proposals. Yes, vendors will also be asking you questions you've never considered (which is a good thing), so be prepared to do additional definition work once you've received the questions from them.Doing this research is part of the Requirements Gathering phase, and will help in the future when moving along to the Contract and Statement of Work part of the process.Step 2: decide your distribution strategy and information publicationHow will you be distributing your RFP, how will you be collecting information from potential vendors, and where will you be providing project updates?Our first recommendation is to create a project page or project site that will house your project overview, contact information, timeline, the RFP for download, and all other project documentation that you need to share with vendors. Include a link to this page in your RFP and direct people to it as a central repository for the project.Our[...]


Media Files:
http://podcasts.confluentforms.com/write-a-rfp-for-best-results.mp3




9 contract tips to save your project from imploding

Thu, 11 Sep 2008 15:39:00 +0000

Contracts have a funny way of bringing enthusiastic and optimistic partners in a project quickly back to earth and miring them in angry back-and-forth that can soil the project before it even starts.The following article is based on our experience issuing contracts for +Confluent Forms LLC as well as reviewing contracts on behalf of clients when performing technology advising services.Be equally fairBy default, lawyers will craft a contract that is the most defensive posture for your company. They want you to be on the safe side and in control. The contract is meant to protect you, give you all the rights, and give nothing to the other side. If both sides take this posture you'll end up in a Mexican Standoff with nothing but empty wasteland between you. Every good contract is built on compromise and the desire to see the project succeed. Too much pessimism can be a huge turnoff.If you make a promise, keep a promiseSalesmen like to be optimistic and promise you the moon, executives want to be realistic and not be held accountable. This behavior often is seen when a sales person promises you the entire project for a specific amount, but then when you read the contract, you see language such as "this is only an estimate and the final project price might vary due to a number of factors". Most customers never notice this line or realize its impact. We have heard of projects in which a price tag of $100,000 was promised, this line was in the contract, and the project ended up costing around $200,000 when all was said and done. Which brings us to our next point...Definition and Statements of WorkDefinition is something often sorely missing from a project. Spending more time defining the project and pricing, and being clear about what the project consists of and how the project will be billed, will save the project from countless misunderstandings, confusion and potential strife. The two sides can be looking at the same one sentence describing a piece of functionality but have widely disparate views on what the description entails. One view could be exceptionally complex and expensive, the other view could be a 30 min endeavor. This can turn into the following exchange:"Well, the SOW says you're going to implement a 'user profile management' feature to the site, but you've made it so it only captures first name, last name, email address and password. We want it to capture that, their home address, business address, areas of expertise, newsletters they'd like to receive, companies they are affiliated with, etc. etc.""None of those things are mentioned in the SOW so they aren't going to be implemented in this project... perhaps an add-on phase?""What do you mean they aren't in the SOW? It says USER PROFILE MANAGEMENT and those are the pieces of information that are captured in our existing system under the user's profile."At which point both sides have the option to stand down and accept the other person's point of view or to fight for their opinion of what is stated in the SOW and both yield to negative feelings. The moral of the story? Definition saves projects.Use project milestones for the payment scheduleWe were once involved in a project where the technology firm wanted 40% of a $100,000 project paid upon signing. There was no mention of this huge upfront payment during the project talks, but then upon receiving the contract, there was an invoice for that whopping amount. Needless to say this left a bad taste in the client's mouth and they immediately balked. It is entirely fair to require a percentage upon initiating the project; it is also entirely fair to require a percentage held until the final project is delivered. But rather than having it be 50% upfront and 50% on completion where the client isn't happy at the beginning and the firm isn't happy at the end, we recommend schedules along the lines of 10%, 17.5%, 17.5%, 17.5%, 17.5%, 20%.Prompt payment and late payment feesA happy contrac[...]