Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> most missteps happen early, dooming projects before anyone sits down to code

This one is more insightful (in the big non-tech enterprise / government spaces). Because the takeaway for most HN developers who flip between projects should be: (1) learn how to recognize one of these projects & (2) stay away / find a new job when you do.

You'll save years of your work.



How might you recognize a project like this?


Ask yourself some critical questions.

- is the scope well defined?

- do I understand the value add and agree with it?

- do I feel as if all stakeholders are aligned and adequately involved?

- do I think the team can pull it off ?

- do I think the mood and style fits myself?

- do I think the timelines and budgets are realisitc?

- do I agree with the level of transparency from management?

Etc etc

Ask yourself these questions - and more - and you will discover the answer for yourself.

In the end listen to your guts.

One important nuance: A project can be a major fail overal but a big success for you. Big check, new knowledge, rich connections...


In addition to what others have said, from my previous experience:

- Does the customer have an IT org capable of fulfilling basic tasks you won't be authorized to do (app / db access, AD / rights modification, firewall adjustment, AV adjustment) in a timely manner?

- Can the customer provision necessary machines in a timely manner? If using VMs, is the virtualization team competent with their chosen platform?

- Does this project directly threaten the job of anyone whose blessing / help is required to successfully deliver the project?

- Is your leadership / your customer champion intelligent and willing enough to say "No" to scope creep when the customer gets excited?

- Do the PMs attached to the project have a basic understanding of how software is built and the systems involved?

- Does their management understand the actual processes being interacted with? (Major red flag! If their management / leaders say things in meetings that demonstrate a basic lack of understanding in what their own people do, run)


I think a tell-tale sign is if they apply the waterfall approach.


That won't save you at all. A lot of federal IT contracts are now written to mandate using Agile or Scrum. Many other forms of dysfunction that doom projects remain.


Didn't the guy who coined the term give it as an example of a development model that never worked?


they will say "agile", but will mean , "all requirements up front with an increment delivered every sprint".

which works very well if the developers and the customer really know what they want when the project starts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: