views:

1216

answers:

15

What do you do when you get assigned a project that is just way too hard to do:

  • Say it's a mammoth project and your boss thinks you alone can handle it
  • You have knowledge to do somethings, but some other things are a little beyond your expertise at this point in time
  • Your boss probably thinks it's something that can be done by one person in probably one month

SO users, I would love realistic answers here. This is a real world situation and I am trying to figure out my response to my boss tomorrow on how to approach him delicately.


I just wanted to add an update to my note here. The app in question that my boss is targeting is a "NING like" web app. My hesitation is mostly being the only person being assigned to it for such a complicated app in such a short time period.

+2  A: 

Would your boss not understand the truth? Just talk to him about the requirements of the project, and mention what can and can't be done.

Andrei Krotkov
+22  A: 

This is a situation that everyone has to deal with on a regular basis simply due to the nature of work. (Typically, if you know everything you need to know to complete a job, you've already completed the job and don't need to do it again. :) )

  1. Be honest with your boss about your anxiety. Your manager needs to understand your assessment of the project's risk profile. Odds are good that you'll be doing it anyway. That's OK! This is your chance to shine! :)

  2. Break the problem down into tasks you understand and tasks you don't understand, then start tackling issues one at a time. I, personally, like to alternate between easy tasks and hard tasks. Completing easy tasks helps me feel like I'm making real progress on a gut level, which is important for my personal motivation. Completing hard tasks addresses potential problem areas earlier in the schedule. This mitigates the tail-end risk of the project by evaluating unknowns earlier, rather than letting them fester and explode when you've got 2 days left and no more planning/wiggle room. It also helps your stress level because you know you've gotten the ball rolling on the project's scary bits. Remember-- your unknown areas are where you don't understand the problem domain, so that's where the real risk of schedule/budget slips lie. You need to mitigate those risks early and often. Get the ball rolling with colleagues that you can consult to learn how to do these things.

  3. The one month goal is probably a target. I don't believe it's reasonable to expect person A to realistically estimate person B's scheduled completion of a task in the general case. To track your progress against the target, set up milestones, none longer than 16 hours/2 days, and track your completion rate against them. This goes hand-in-hand with your list of easy/hard tasks.

  4. The simple fact is that, sometimes, you'll just get dumped in over your head. In that case, you may have to make the best of an overwhelming situation. My very first task at my first job out of college was to design a reliable, transaction-oriented, peer-to-peer n-way server synchronization system for high-volume, high-rate data. I told my boss up front that I did not have the expertise for this, and at the time I didn't have enough experience to understand that I needed to push back on the requirements. (In retrospect, given the political environment, I don't know if pushing back on the requirements would really have helped anyway). That was simply a case of a poorly managed project that took about 18 months to ultimately collapse under its own weight. I still leveraged the opportunity to learn a lot and take some knowledge about the way my particular organization worked, though, and that can be very valuable no matter what. :)

Good luck! :)

Edit after question update

Ok, if I understand your update correctly, we're definitely in #4 territory here. There's nothing realistic about creating a competitor for Ning in one man-month. I assumed in my prior answer that you were dealing with someone who had a base understanding of software development. Based on that:

  1. Ask your boss to clarify the requirements more. Perhaps (cross your fingers!) you simply misunderstood what you were being asked to do, or the scope of the project. Always assume competence until absolutely proven otherwise for social reasons. Maybe you were only being asked to come up with an overall design and some very simple proof of concept?

  2. If your boss is truly this out of touch with reality, put together a sensible, 15-minute back-of-the-envelope estimate with him/her on a whiteboard or a shared piece of paper. It shouldn't be hard at all to blow all kinds of holes in this one month to completion. Perhaps your boss thinks you'll be able to reuse some internal code that you're not aware of? This will bring any faulty assumptions your manager is making re: project scope to light.

  3. If your boss is absolutely unreasonable (this doesn't happen often, but it occasionally does-- perhaps the company needs a killer app by the end of the month to sell to avoid going under), prep your resume for an intra- or extra-organizational move (depending on how big the place you work is). Unrealistic expectations on that order can be a sign of organizational desperation or malfunction, and your position may simply not exist 3 months from now.

Greg D
Wished 1 was true. I just got the documentation today and it blew me away. I will try no 2, but just in case, I have started on Monster. :(
Greg D
A: 

It really depends on the relationship you have with your boss. If you can, I would just be open and honest with them. Tell them a few things are beyond your level of expertise and you would have to do some research, lengthening the project time. And stress the point that you don't believe you can get it done in a month and you're requesting a team to help.

It's possible your boss doesn't really understand the full scope of the project. If you can break it down into a list of tasks or sections to show how much work really has to go into it, they might see where you're coming from.

In the end, if your boss still wants you to go through with it, just keep stressing that you will do your best but you cannot make any promises about the deadline.

lc
A: 

You need to be realistic with your boss. You will come out much better having over-delivered on the project rather than under-delivering on an aggressive timeline.

dnewcome
A: 

You have to be honest and tell the boss that there's a problem. However you need to show how much exactly of a problem it is so that you don't sound like an incompetent person waiting for a pink slip.

You need to carefully analyze what is to be done and break it into small parts and see which of them you can do and which you can't. It's normal to have parts in the project which look possible but hard to do - every normal boss usderstands that.

This way you show that the problem is not imaginary and it's not your desire to get nice salary for trivial job.

sharptooth
+5  A: 

Don't start by saying "No" or "It can't be done" or "Its too hard" or any of the other things you said in your post. Most managers in a company do not even begin to understand the effort level involved in a programming project and need a little education with their software planning estimates.

I would suggest a conversation which includes the following steps.

  • Estimates: review the effort level you believe is required for this project to be a success. Make sure that you have thought out tasks in enough detail so that you can answer questions.
  • Education: if your boss doesn't understand why something will take a certain amount of time, explain as clearly as you can (good analogies tend to help, bad ones can be devastating).
  • Alternatives: if you believe there is some middle ground or some set of sub features which will fulfill the project needs discuss these alternatives. Managers hate when an employee says something is hard or difficult, they want workable options.
  • Alignment: are you sure that you and your boss are on the same page about this project? Perhaps you see it as a piece of mission critical software and your boss sees it as a minor enhancement to your existing tools. Be sure that you both have the same expectations; otherwise, you may be planning more complex software than what is being requested.
jellomonkey
But what to do when an employee has no workable option to provide??
rahul
In my experience it is the rare situation where some type of compromise cannot be arranged. Maybe it is a phased implementation where only some functionality is initially released. The only time when you cannot compromise is when you don't have the skills to deliver even a sub-set of the requested functionality or your boss is both stupid AND evil.
jellomonkey
Am I the only one who thought "Chaotic Neutral" when seeing the 'Alignment' bullet?
Erik Forbes
A: 

The truth of course is always the right answer, which your boss will find out eventually, better to fail early.

But with that said, is it something you just don't want to be involved in. Make sure you explain to your boss that you don't want to commit to something that you're sure to fail at but let him know that it could be a learning experience and at least be involved at some level, even if it's to look at the solution after it's done.

Joshua Belden
A: 

Create a realistic schedule and present it to your boss. Ask your boss for his input regarding the schedule. Maintain a positive attitude and let him know that you are both working toward the same end goal. Tell him that this is your best professional estimation of the amount of effort needed to meet all the requirements. Point out where the complexities are if challenged. Be firm and clear and above all else give him an opportunity to speak his concerns. Demonstrate good listening skills and address each of the issues he presents in a language that he feels comfortable with. I wish you all possible success in your project.

ojblass
A: 

If estimations are not yet there then your first task is to do a realistic project estimation. Second task would be to check what technologies are required for the project and check if the knowledge is already available. If not then estimate for the training and gaining the knowledge. I understand boss is boss but you do your part and rest is up-to him. If the boss appreciate others opinion then he will understand but if he is like "I am always right" then you do whatever you can(work as best you can and also look for a new job).

Bhushan
+9  A: 
  1. Don't panic. You may have misinterpreted the goal your boss has. It sounds like he was not very clear if he said only "Ning-like."

  2. Research Ning. What are all the things Ning can do? On Ning's Resources link, they list at least 21 major social network features.

  3. Write up a high-level statement of the goal for this project. Include all the features Ning lists. Also include an objective for how many users this app should serve. Don't try to think about how to solve these goals objectives, or how many programmers it'll take or how long it'll take. Just list them. Keep this write-up to one or two pages.

  4. Present the list to your boss. Ask him, "does this sound like what you had in mind?" Ask a few direct questions to ensure he has looked at your write-up:

    • "Who are the target users for this application?"
    • "How many new users per month do you expect to sign up?"
    • "What level of uptime do we need to support?"
    • "What's our budget for hosting this service?"
    • "Do you need this application to support international users?"
    • "What is the end-user license agreement (EULA) for this application?"
  5. It may become clear at this point that your boss has more modest goals than you assumed. Perhaps he does not intend to duplicate all the capabilities and scale of Ning. So then it becomes a task of getting your boss to articulate more clearly what subset of Ning features or capacity he needs.

  6. Install Drupal, Joomla, or Wordpress, download some plugins, and design a custom site for your boss. That'll probably give him 99% of what he wants, and it's the only way you'll be able to do it in one month.

Bill Karwin
+1 packaged solutions.
epochwolf
Absolutely. Personally I'd be looking at whether ELGG http://www.elgg.org/about.php can do the job.
timday
In fact, another option might be Ning.com. :)
Bill Karwin
+2  A: 

The most important thing I ever learned in software was how to "push back."

It doesn't always mean saying no. What it means is providing your best estimate of what the impact of new work is. Whether you're saying "yes" or "no", you say, "we can do that, but it will require (x, y and z resource). I think it will take (n days for me, n*a for person b) to understand problem b), but I know how to handle (c, d and e). I've never had to solve problem b before, so I don't know if my estimate for that is realistic."

The difference between "yes" and "no" is whether the cost equation is acceptable.

Any good manager will respect your analysis, question some of your assumptions, expect a round of rethinking, and then, either accept the risks, find additional resources, or abandon the project.

If they say "I see what you're saying, but you're going to have to accomplish the impossible anyway," start looking for another job.

JasonTrue
A: 

What you say is that your perception of the task scope and complexity differs greatly from the perception your boss has. Great.

Most likely you're both wrong: you have misunderstood the requirements and the boss underestimated the task or fell into the trap of wishful thinking.

It's best to go through the requirements with your boss once again, work out together that deliverables are required, try to guestimate amount of time and resource needed to deliver these. If there are blind spots in implementation that you feel you lack skills or expirience for, make this clear and work on the assumption that you'll have spend cash to source these externally (that will at least give you an idea of a market price).

I am sure, the longer you and your boss spend discussing and researching the project, the more detailed the dissussions will become and the better idea of what is feasible will emerge.

The worst thing you can do is to keep quiet. Any good boss relies on developers to give some assessment of a project: either affirmative or hear more questions.

You don't have to say "no", that's not your job to decide whether to go ahead, but you have to be asking good questions.

Totophil
A: 

Go fight club on him? Get free monies and airfare!

Chad Grant
+1  A: 

Here's how I would plan it out:

  1. Don't panic and to react - tell your boss that you would like to review the request and will get back to him shortly with questions and concerns
  2. Go through the spec (or if there is no spec, the email or write down the request somewhere) and create a work breakdown structure for each delivery. This should be done to a level where each item is understandable (User Login, Message Entry, etc.)
  3. For each item, est. the amount of work and +/- % amt. based on your knowledge, questions, risks, etc.
  4. Create a list as you're going through the spec of any major/important questions (how many people is this targeted for? does this include the ability for users to IM, etc.)

You now have a rough timeline, risk assessment and list of questions to review with your boss. He'll see that you put some effort into it, may open his eyes to the complexity and provide him with confidence that you are not knee-jerking reacting. He might demand you do it in the timeframe he provided anyway....look for another job, you have at least a month.

meade
A: 

Its a bit on the side of all the good advice I've seen here, but I'll say it anyway: most managers are actually quite smart. Senior managers I've met have all been very smart. The problem is that, as Eric Raymond puts it, they are "differently optimised". So they may need some education. If you assume that they will be reasonable once they know all the facts then you will almost always be correct.

Of course you do occasionally get people who behave unreasonably, or think that saying "make it so" like Captain Picard is Leadership. But they are rare, and do not last long.

Paul Johnson