↳
I believe the point here is not saying that you should/have a back-up plan for this (you can mention that at first, but then assume that something went terribly wrong)... So in my case I would go through the how crucial is this program/component for the launch? can be fixed with an update? how much time/resources are needed to meet the deadline? what would be the impact of delaying the launch until the problem is solved? is it feasible? after the brainstorming and impact analysis you could take the decision of delaying, solve the problem or ship everything as-is and fix the problem afterwards. Once the problem is solved you should go through the situation again and understand what went wrong and prevent it from happening again. Less
↳
Alvaro is right. The question is about how pragmatic and adaptable you are.
↳
I said you look for other solutions, off the shelf parts. I "think" the answer was go ahead and launch and do a redesign after launch. Of course, if it fails how do you launch right? Less
↳
First, I will try to figure out how important these 20 extra features, whether some or all of them are 'must have', 'should have','could have' or 'nice to have'. I would totally rule out any 'could have' or 'nice to have'. A project/program manager must have courage and conviction to say 'no'. If some or all of those features are 'must have' or 'should have', then I will see what features in current project/program can be dropped in favor of the new features. use creative project/program planning or use overtime as much as possible without adding extra risk. If none of the above is true, then extra resources or time must be negotiated. Through analysis of the situation and clear communication is key to achieve this objective. Less
↳
It's always about trade offs. Add the 20 requested features to the list - then sit with stakeholders (marketing, engineering, etc) and sort the list by priority and by ease of implementation. Customer must haves should come first and these hopefully were articulated when the core product was conceived and started. Include in the list the level of completion of the features. Completed ones are done, move them below the line. Review the remaining - which can be completed in remaining time with available resources and which have to be dropped. Be the strong project manager and present to management. If the company only wants yes persons with no critical thinking skills, you probably don't want the job anyway. Less
↳
For SW projects, we have to freeze requirements, scope, they can not change after a certain phase. Else developers has to start the design phase. I will take the 20 items to my dev team and ask what can be accommodated with minimal changes to existing plan. Ultimately business needs over-write all others. Less
↳
I'd say 9, since the three bits you have mentioned have to be multiplied by the three user groups (owner, group, others). rwxrwxrwx Less
↳
9 is closest, but you may have forgotten about 3 more bits used for special access; setgid, setuid, and the sticky bit. Which makes 12. They are part of the inode that describes the file permissions and file type - the last 4 are the file type but not related to permissions, which is what the question asked. Less
↳
Traditional Unix permissions are broken down into: so answer is 3 read (r) write (w) execute file/access directory (x) Each of those is stored as a bit, where 1 means permitted and 0 means not permitted. Less
↳
Good Communication skills Being a good leader Good negotiation and persuasion skills Good team building skills Good team motivational skills Good manager of time, cost and resources Escalate an issue when product scope/functinality changes or deviates from project charter Less
↳
Communication, management of time and money, keep the end in mind. Escalation is needed when the project schedule or product functionality are at risk. Less
↳
feedback.
↳
Good leadership. You may need to sit that person down and tell him or her how valued and appreciated they are but they are being held back by some issue. You've also got to find the right person for each role. Square pegs never fit in rounds holes, at least not without a lot of pain. Less
↳
1) My project management style is detailed and organized with a high level of communication with my team. I believe in investing heavily in the planning phase of a program, so the execution phase of a program can happen as smoothly as possible. 2) I protect my engineering team by trying to give them as much time as possible in the schedule to build their best design. On tight turnaround programs I communicate upcoming deadlines with them as early as possible so they can plan their own workload. During design and execution, I protect the engineering team from scope creep emphasizing solving the problem as posed. 4) When approaching a vague problem, I would first ask to clarify the end goal of the project. Hopefully that end goal can help me work with the sponsor to define project objectives. I will then ask for a project budget and deadline. I would bring a program proposal back to the sponsor and get their feedback to either go back and update, or move forward with the program. Less
↳
I would protect my engineering group by making sure that engineers are not distracted and avoid context switching, as much as possible, once they have started working on the project. If the project has a very high level and vague requirements then I would start working with the product and engineering team to narrow down the requirements and create a proof-of-concept for the customer. Understand what are the customer requirements and work backwards to address the problem. Once the initial spike is done by the team and prototype has been demonstrated. This would be a good time to write the requirements with detailed use cases. Less
↳
If they ask for more features beyond what's in the agreed upon contract SOW and requirements, then you'll have to renegotiate the project cost and schedule. As for you being currently behind schedule, you always have to manage your customer/stakeholder expectations. They should know you are behind schedule, what your doing to get back on track, or why getting back on track is not possible. Less
↳
initiating, planning, executing, monitoring and control and closing
↳
elaborate more on the above processes with examples