Office Home And Student Seven strategies for resol

Recently,Office Professional 2010, I was asked the following question:

All of my Access work has always been my sole responsibility and I have been accustomed to making all the design and development decisions, and doing all the work myself. I am now attempting to work on a project with someone else. The person managing the project doesn't have a firm grasp on software or database design principles. The project is potentially good for me as it will provide an opportunity to learn about SharePoint and Access 2007.
Today came home from another session of trying to bash square pegs into round holes,Office Home And Student, feeling rather despondent. The problem is that there are a number of aspects of the project design concept (formulated before I came on the scene) which are counter to correct database modeling. My attempts to discuss the problems have failed to make progress. This is a classic case of non-technical people having been allowed to influence technical decisions. I don't want to give up. But at the same time, I feel my integrity is being compromised if I continue to build something that I believe is flawed.
Any advice?
Everyone that works in software struggles with this question from time to time. I haven't worked on a team yet where there weren't things I wish we would do differently. On a regular basis large battles will erupt between very smart people about different visual and technical design decisions. Here are seven strategies I try to use to make the best decision:
Clear goals and scenarios. Make sure the goals and customer scenarios are clearly understood before diving into the design. Different goals and scenarios will always lead to different designs. Many times this requires making hard trade-offs because it is rare you can satisfy everyone's requirements with one design. Clear goals and scenarios make it easier for people to let go of positions when they understand how the technical design aligns with the higher mission. This is invaluable for your career as you move up the food chain.
Open and respectful. I wrote a post a while back about being open and respectful. The ideas in that article very much apply. Use inclusive language and give credit where credit is due. Find areas where everyone agrees and try to build on it. Keep the discussion focused on the ideas and try not to closely associate ideas with a particular person (i.e Mike's plan and my plan). As soon as the discussion turns into a win/loss conversation making the right decision gets infinitely harder. It is natural for people to hold on to a position because they don't want to look stupid.
Give escape hatches. Look for opportunities to give people graceful ways to exit their position. Reiterating their contributions and highlighting new information that changes the discussion help provide an emotional exit strategy. Keep telling yourself it isn't about being "right" but getting the right design for the customer scenarios.
Provide alternatives. Generally speaking,Office 2007 Key, I find the best decision is an amalgamation of different ideas. Greg Lindhorst on the Access team taught me years ago how to compare and contrast two different approaches. Slides or email that outline goals, scenarios, and different proposals with strengths and weaknesses give people choices. They also help you focus on the heart of the issue. Usually,Office 2010 Key, I find the right answer is a combination of the different alternatives. Once people see alternatives spelled out it frees them to think about smaller tweaks as they focus on mitigating the weaknesses and pulling in strengths from the other design.
Facts based decisions. Quick prototypes are the best way to get to the facts. It is hard to argue with numbers and facts based on clear technical data. Backup your position with hard data (a query takes x amount of time verses b that takes y amount of time). Prototypes (and especially performance tests) can be a life saver when it comes to choosing a design. You don't have to have everything done but enough to get an idea about the design implications. I tell everyone on my team to never finalize any UI design until after they have watched people try and use it. Many times ten minutes with friends and family conducting informal usability studies are more valuable than formal structured studies that take weeks to execute.
Think long-term. Make people think about the long term implication of the decision. Once the feature is ready to test the costs just begin. You have to fix bugs, document it, support it, etc. Articulating the long-term impact positions you as a more strategic thinker and is a critical step in moving up the food chain.
Pick your battles. Some things just don’t need to get fought out, and opting out of the conflict is both a good solution and can build social capital to use for more important conflicts. For example, projects should have naming conventions, and there are several different ones to choose from. Although we all passionately believe that ours is best and can argue for hours about why,Office Home And Student, this is a great case where caving in is usually better than fighting to the death.
Undoubtedly, it is tough when you are forced to go down a different path than your preference. Once a decision is made--either get on the train or get off. Don't stick around and undermine the plan. It won't help your career or the product. Personally, I don't mind a knuckle head decision or two if I agree with the broader long-term vision.
Do you have any suggestions for resolving technical design conflicts?
<div