Problematic Stakeholder: How can I make this work?
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
"Start with the first screen" was the best way to create a big, bold, and messy amount of spaghetti code developing under MS-DOS. I lived it a few times before I learned how to create structured code less hard to be understandable and updatable, until I switch to OOP, and that makes my life easier. Have you tried to invite your stakeholder to drink any beers out of office? This may enhance a lot your communication with him. In the other hand, why not the first screen is the logon screen? And the second screen is the main menu screen? After that you can work defining the users and security screen, and perhaps your boss will be more willing to cooperate when he sees your progress.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
You know, from your description, it sounds like the owner uses confontation and competition to motivate his people to perform. Are you sure that he understands the original application? Did he specify it, or was it developed by a collaboration between a developer and the employees? Or could it be that he wants an incremental approach because he wants to gain confidence that his investment is going to pay off? Maybe the "first screen" isn't the first screen in the application, but the "first thing you can do that is useful for his people." In other words, you may be asking questions of the wrong person. Find a problem that people need solved and demonstrate how the techniques you apply generate a win for everyone involved.
-
Your response will not earn you points. I've learned the hard way that the response is right on. If you fail to see that, then perhaps programming is not for you.
Gus Gustafson
Although I don't agree with the tone of the answer, I do kind of agree with the message. I think you're trying to play basket ball with foot ball rules. He obviously is not interested in going a "traditional" route of explaining every intricacy of the application, go through all the hypothetical scenarios, and mentally building the solution in his head and envisioning it before you code. The thought that you could change that is, in my opinion, wrongheaded and doomed to cost way more in the long run, contrary to what people are saying here. I think the teachable moment here is indeed for you, not him. This is a good example of why "traditional" methods perform very poorly, and why an "iterative", and more so "lean", approach is a better tool for this job. DO take this mock up and DO create a, more or less, wireframe app around it. Do this quickly and do not think too much about it. You will find that by giving him a more concrete example of the application and flow you will learn much more and much faster. Once he sees it for his own eyes and does not have to think abstractly about the application, I think you'll find that he will describe it more and more. Perhaps even create that fast screen, and after that, do think about it and create a different screen with things tweaked in the direction you'd like to take things as you see them now. He'll tell you where you are right and where you are wrong. If everyone had the ability to visualize a complex system like you are building (why you building one rather than buying one would be my first question, anyways) then no one would need your skills. His skills are obviously more interpersonal or sales related. I'm not sure what mix you have, but I think the FIRST thing you need to realize is that you CANNOT change someone fundamentally. You need to look at things differently and seriously challenge yourself to find a way to take his strengths and utilize them, rather than fix his weaknesses. (Hmmm... I think there's a book about that... right? :-\ )
-
Please tell me you don't "develop" line of business apps like that?? After 35+ years of designing and writing code, that approach just doesn't work. This guy has a problem in that his boss doesn't understand that HE needs to be a teacher as well and educate him on how the business processes work. Without that, you've got a "pretty" screen that looks good to him but is utter confusion behind those fields. I've heard it referred to it as "putting a dress on a pig".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
So, you can tell how a system works and what the rules behind it are just from a mockup? Wow, that is some talent you have there. Personally, I like to explore something called the use cases, but I'm quaint like that. You know, those things such as if I press a button here, what happens next.
Pete O'Hanlon wrote:
So, you can tell how a system works and what the rules behind it are just from a mockup? Wow, that is some talent you have there. Personally, I like to explore something called the use cases,
Myself I would prefer to have all the business requirements handed to me by a knowledgeable business analyst who has had a lot of previous experience both in the company, the industry and with writing business requirements. But I gave up on fantasy scenarios a long time ago (and I can assure you that it wasn't easy.) But in the mean time the OP stated that the person with the knowledge will NOT do what you are suggesting. And the OP isn't willing to quit either. So exactly where do you think that these two individuals are going to start?
-
Actually I disagree with you to a degree, IMHO you MUST go for the best outcome, the OP has obviously exhausted his own ideas and is looking for new ones. Just buckling under and creating rubbish (what the owner wants) knowing it will be a disaster is wrong. He needs to push back on the owner, whether with education or just being a more stubborn bastard or both, but it needs to be done. Worst case is he gets fired so this must be mitigated by the OPs personal situation.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
and creating rubbish (what the owner wants) knowing it will be a disaster is wrong.
Just to be clear there is nothing that suggests to me that the suggested application is absolutely "rubbish". It might be. But lacking real knowledge of the actual business processes that are being modeled it is rather hard to state that. And from the question posted the OP doesn't know what those business processes are either.
Mycroft Holmes wrote:
He needs to push back on the owner,
Or he creates the application. And then the user(s) start wondering what else is possible and then that gets added in the next version.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
I have been an "only in-house developer" for most of the last 15 years and here is my advice: Your boss does not know or care how the software works, only that it does. Knowing stuff is your job. In order to do that, you must first figure out what they have now... if you need to draw it out, do it for yourself at your desk. Watch the office staff.(Be a fly on the wall if possible.) Look at all the inputs into the system and the outputs. Structure the data as you see fit (just be sure you understand when, where, and how the data is used). When you design the interface... DO NOT GET CREATIVE. Even if you have a design that is 100 times better, it will be met with resistance if it is too different from what users are used to. You will do better by modeling your layouts off the old system, only making minor changes to make the user experience better(this means fewer key stokes, remove unneeded fields, automating tasks, ...). This will allow the company to implement your system with little to no training of the users. The only times your boss wants to hear from you is: if you are coding an 'edge case' and want to know how he would like to handle that situation(best to do this by email if you can, or do a paper sheet of some kind, make him sign off and keep it. That will save you in years to come if you're are still around there) Or... You just implemented something.
Long time, only, lonely, in-house, developer.
-
I agree with this, but would add: Start with a quick (and possibly ninja-like) run through of the data and business process (input from A, B, and C, goes to E, checks with E, and gets dumped into reports and screens F-Z). Then, if you think you have a good enough sense of the system, pick a small piece of the system to replace--one that can be swapped in with a better looking UI or more efficient transfer/transform. If you can hook into the right fields individually, maybe a particular user just needs to be able to check a box or set a status. Maybe the output reports are old and stale, and there is a little more data or a better layout that will help the business. Because he wants to see results now, I imagine that he also won't accept downtime. I've worked on quite a few of these (vague "make it better" requirements, system is seen as absolutely vital, etc), and this approach has generally worked to win over the stakeholder and the other users. The one who gets the first improvement--if they like it--usually becomes your friend and unofficial advocate. If it goes well, people will come by to teach you both how it works and what they need to run better. All you have to do is keep the current and improved parts straight in your head while you adjust. At some point, you'll probably reach a time where a fundamental aspect will have to be upgraded--new database, move to a different server, whatever. By then, you should have a track record that will carry weight, and enough happy personnel to back you up. It's dangerous--like modifying an airplane while it's still in the air--but when given impossible demands, you have to start with the small possible bits.
David Days wrote:
It's dangerous--like modifying an airplane while it's still in the air--but when given impossible demands, you have to start with the small possible bits.
And there really isn't anything quite like developing on a live system. :-D Just be sure you can get yourself out of trouble if the worst happens.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
Hi there You have had much advice about this being a nightmare scenario, and there is the potential for this turning into a massive bag of unmaintainable spaghetti code - and I have to agree, but I feel you are looking for practical approaches. I don't know what business the company is in, but there must be certain things that are obvious candidates for objects (people, buildings, invoices), some of which will be more central than others. There is usually a 'way-in' object - ie when somebody calls a user with a query, the user will ask for one or more bits of information in order to find the relevant stuff. Start here & look at the data store to find out what information is held about it (don't go too many levels deep into related stuff) to plan a set of object with all the data exposed & enough for CRUD. Write tests to verify the results that you expect, then implement code to pass the tests. This way you have verifiably working stuff that you can put behind part of a front-end. Once you have wired this up, you then have your first screen to demo. Don't spend too long doing this, cos it'll be wrong - see it as slow prototyping, as it sounds like you wont get the chance to throw away what you have developed, but will have to modify it. If you keep the UI free from Once you have something concrete to demo,discuss & play with, you will have ample opportunity to ask the questions that you need answers to to aid further, better development. Some people can work like this, others aren't cut out for it - only you can decide which camp you fall into. Hope this helps. Regards, Stewart
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
What about finding some examples of screens for similar apps in his industry to use to illustrate ideas for discussion. You don't have to use them exactly but he may accept that they are good examples if he feels these companies are successful or in some other way memorable to him. This has worked for me in the past as at least an ice-breaker. Can you get input from operations people to discuss with him as needs his key people are looking for. Maybe some emails from them or create some flow and screens with them for him to review. In other words educate him and get him looking at this as a team effort rather than adversarial. FWIIW.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
Go through the new screen with a knowledgeable user, then get him to tell the boss it's crap and will cost him customers.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
One thing I would suggest if you think the owner has the patience for it, is to ask what are his favorite things about the mockup the designer did. I've done this for a few mockups and sometimes been astounded at what the responses are. The favorite thing may be that she used so much orange that matched the company logo or that the buttons have rounded corners that the owner thinks look more modern than the legacy system. I'm not kidding. I've gotten responses like this in the past that had nothing to do with how the system worked. Finding out what makes this design a success in the owners eyes will help you know what is important to preserve and where you can suggest changes.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
The Boss seems to act like he's the only user of the system. You might try breaking the project definition into "user views of the business process," giving the importance of his complex overview prominent recognition. At the same time, you need to collect what are the needs and hurdles of the other employees as they do their daily work. Try to enlist the support of the employee he needs/trusts most to work with you on project definition and present some (not all!) of the employee's important needs to Boss. Try to get him work with the employee and you together to optimize business processes. Be sure to be seen as paying attention to the Boss's ideas, then refine them with the employee later. Sometimes the key employee can present ideas which would be immediately rejected if they came from an outsider. Perhaps the Boss is trying to deal with a business perceived as slipping out of his control and wants a complex dashboard that only HE/SHE can understand ... that's trouble for you and may explain why he's so reluctant to share business processes with you. Good luck, if that's the case. On the other hand, if he really wants to grow the business and trusts his employees he needs to understand that different employees can work more efficiently with their own constrained view of the business processes and that giving everyone the big dashboard view is a threat to the security of his business model. A few off-work team building sessions with you, a favored employee and Boss might help. Go out for dinner and drinks to try to break the ice.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
Analogies are your friend. It would help to know what industry you are working with to make them more pertinent. Say you are going to build cars. You start with a frame, then you add wheels. So you setup your assembly line to build a frame and then add wheels. After ten cars roll through you realize they need brakes. So now you have to dismantle those cars, and completely re-tool your assembly line. You do that over and over with each feature/part and then you realize that the warehouse you bought isn't big enough for all of the stations you need in your assembly line. An ERP application is the assembly line for every transaction in his business.
-
Although I don't agree with the tone of the answer, I do kind of agree with the message. I think you're trying to play basket ball with foot ball rules. He obviously is not interested in going a "traditional" route of explaining every intricacy of the application, go through all the hypothetical scenarios, and mentally building the solution in his head and envisioning it before you code. The thought that you could change that is, in my opinion, wrongheaded and doomed to cost way more in the long run, contrary to what people are saying here. I think the teachable moment here is indeed for you, not him. This is a good example of why "traditional" methods perform very poorly, and why an "iterative", and more so "lean", approach is a better tool for this job. DO take this mock up and DO create a, more or less, wireframe app around it. Do this quickly and do not think too much about it. You will find that by giving him a more concrete example of the application and flow you will learn much more and much faster. Once he sees it for his own eyes and does not have to think abstractly about the application, I think you'll find that he will describe it more and more. Perhaps even create that fast screen, and after that, do think about it and create a different screen with things tweaked in the direction you'd like to take things as you see them now. He'll tell you where you are right and where you are wrong. If everyone had the ability to visualize a complex system like you are building (why you building one rather than buying one would be my first question, anyways) then no one would need your skills. His skills are obviously more interpersonal or sales related. I'm not sure what mix you have, but I think the FIRST thing you need to realize is that you CANNOT change someone fundamentally. You need to look at things differently and seriously challenge yourself to find a way to take his strengths and utilize them, rather than fix his weaknesses. (Hmmm... I think there's a book about that... right? :-\ )
Well said, @cwmillerli! Some kind of Upside Down Aikido Programming... ;-) Here is the thing: Since you don't want to quit, one of you two guys will have to be flexible, at least at the beginning, and that is you. Before the boss will listen to you, you first have to gain his trust. To do that, he needs to feel that you take him seriously and that you listen to his needs. Giving him that first screen will do that, so do it. Tell him just once very strongly but shortly, with whitness or proof to support it later, that his methode will cost more money and time at long term. You can then recall this moment later when things really get out of hands. Make sure you avoid repeating it after having said it. What's the big deal if you have to rebuild to often because of his approach? You don't want to leave, he is not listening but it's his company! You don't have a choice. Do you? Some people only listen when they get hit. So let him feel the consequences of his methode if you're so sure that is what will happen finally. What do you care? It's his company, not yours. And if this really get bad along the way, well, you've told him, right! If you feel you can code in such a way to limit the dammages because of his approach, do that. If it's too much work for you, leave it. One positive thing is that you'll be having a job because there is so much to do/fix. That counts too. It won't be your fault if the project takes too long, so why bother? We, at CodeProject, we all know you've tried :-) Good luck!
-
Although I don't agree with the tone of the answer, I do kind of agree with the message. I think you're trying to play basket ball with foot ball rules. He obviously is not interested in going a "traditional" route of explaining every intricacy of the application, go through all the hypothetical scenarios, and mentally building the solution in his head and envisioning it before you code. The thought that you could change that is, in my opinion, wrongheaded and doomed to cost way more in the long run, contrary to what people are saying here. I think the teachable moment here is indeed for you, not him. This is a good example of why "traditional" methods perform very poorly, and why an "iterative", and more so "lean", approach is a better tool for this job. DO take this mock up and DO create a, more or less, wireframe app around it. Do this quickly and do not think too much about it. You will find that by giving him a more concrete example of the application and flow you will learn much more and much faster. Once he sees it for his own eyes and does not have to think abstractly about the application, I think you'll find that he will describe it more and more. Perhaps even create that fast screen, and after that, do think about it and create a different screen with things tweaked in the direction you'd like to take things as you see them now. He'll tell you where you are right and where you are wrong. If everyone had the ability to visualize a complex system like you are building (why you building one rather than buying one would be my first question, anyways) then no one would need your skills. His skills are obviously more interpersonal or sales related. I'm not sure what mix you have, but I think the FIRST thing you need to realize is that you CANNOT change someone fundamentally. You need to look at things differently and seriously challenge yourself to find a way to take his strengths and utilize them, rather than fix his weaknesses. (Hmmm... I think there's a book about that... right? :-\ )
Yes, the owner is begging for an agile project here!! Agile is the type of development he's wanting and heck, OP, why not go that route? The OP could start with this screen the owner designed that does nothing actually behind the scenes, sure, but is what he (and hopefully other users! understand and want). Then you say, ok, what part do you want me to work on in the first 2 weeks? He tells you and you go work on that. You bring back to him in couple weeks what you have and repeat. When he sees that in the 3rd sprint as you all get deeper into it that you have to now rework stuff from sprint 1 or 2, and that it will take some time to do that in the current sprint, he might start seeing how you being told stuff up front, at some base level of knowledge shared, will be beneficial to him as well. Now, you have a very valid concern about the business domain. ..understanding that so you know how to design (re-design) the database. .no getting around that. But maybe you could make class objects for now and use those, then you'd learn as you go what these are and how they relate, and these become your tables. Dunno, but I agree with those saying you'll find it very difficult not operating iteratively like he's asking and there are good aspects to this as well.
-
Some very good advice from the others so far. I find it helps to have a few real-world analogies at hand to illustrate the need for analysis and planning. For example you could take the example of a company ordering a fleet of trucks and then finding out that the pallets you use don't quite fit 4 abreast so you lose 25% delivery capacity. The solution is to either replace the whole fleet (expensive) or redesign the pallets (non-standard solution) with a knock-on effect on product package sizes as a whole. I'm sure that you can come up with something suitable for his mind-set.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
What a classic: I want 5 pounds of software ... and make it purple! There's plenty of good advice been given already, but with an obstinate client they may still get nowhere. Perversely, the most difficult clients can become your biggest fans in the long run, but it's a long painful road to get there. Generally, contract positions can get away with being more direct, but in-house you get less listening and more "just do it!" If the other approaches don't work, the best suggestion I can make is to do it his way (sort of). Start by building a prototype. Call a review meeting and let the other staff pull it to pieces. Keep the ball rolling by throwing in your own observations/questions: "How about this scenario, how should we deal with that?" Some people are concrete thinkers and need to visualize; we programmers tend to be abstract/conceptual and we can give a concrete thinker a headache! You could ask him to nominate one or two go-to people when he's too busy to answer your questions, then rely on these to build your knowledge. Review comments can be very useful in understanding the business and the process bottlenecks. Make meetings short, productive and frequent; make sure you have material to cover or cancel the meeting. When he evades questions and gets aggressive, back off and follow up by email. Use examples he might understand. Iterate prototypes to show progress and converge to an adequate solution. Look at what competitors are doing (if you can) and be more open about the business type. There are a lot of experienced people on CP - use them! Knowledge elicitation is often a challenge and takes experience. Sometimes it seems easy, but you'll find the pleasant person that instructed you was trying to help you by simpifying, only to find later that you are missing loads of "edge cases". Look out for weasel words (like "usually", "almost never", "I don't think you need worry about that"). Sometimes you get no feedback and project failure is "your fault". Good luck and good for you for sticking to it!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
Do you have access to the DOS code? Could you figure out what it does and duplicate it in ASP.NET? An application does not have to be a normalized, objectified work of perfection. This guy obviously does not want to be "Educated", so I would not try. If you see obvious design problems along the way, you could tackle them a bit at a time when you get to them, even if that means rewriting a lot of your code.
-
I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?
So, the owner actually said: “replace (my) failing DOS-based ERP with an ‘ASP.NET solution’”? … And replace my DOS / dBase II / whatever based file system with (for example) SQL Server Enterprise Edition? I get the sense that someone is trying to sell the owner something ("leading-edge") he may not need, want, or can afford; without even addressing what it is that is “failing”. Perhaps, all he needs is “QuickBooks”. ERP systems are made up of multiple "sub-systems". One does not typically replace the whole thing in one fell swoop. You identify the biggest "pain point" and go from there. If the owner says he wants to "replace" his existing ERP system, the easiest way to get him talking is to respond "why?" (Though I doubt that he actually said he wanted to "replace" it).