Often times at work and internships we are asked to work on a project and do a presentation at the end of it. Projects can be of different scope and complexity. The timeline and the delivery also differs according to the scope as well as when it is needed. It is always important to estimate and come up with how much can be done before setting a delivery date. If you need to hit a deadline, for example at the end of an internship, you can also work backwards and narrow the scope depending on how much time is available during the internship.
At school I was taking a software studio class where students could choose their own projects. Since we only had two weeks time before the deadline, we had to choose our project wisely and narrow the scope. I had four people in my team and we brainstormed various ideas for the project. Finally we settled on the idea of creating a website which would help students find study partners. Students could sign up to our system at the beginning of the academic year and we would help match them with other study partners depending on their schedules. Even though this is a simple idea it could have quickly grown big if we had not planned ahead with our deadline in mind. We kept things simple and divided the tasks and we were able to deliver on time.
However quite opposite to this, things did not work out quite as well during my first assignment at work. We were building a simple interview platform. We started thinking about how we could automate the interview generation process. Then we thought about giving our program managers the ability to edit the interview questions themselves. The project scope grew so much in size that we lost sight of the original problem that we were trying to solve. We wouldn’t have not come across his problem had we thought about the timeline and planned carefully ahead.
Presenting to a multilevel audience comes with opportunities and risks. As an engineer it is a great chance to show what you have done. People will know you through the products you create. Presentations you give about your projects can add to your credibility as an engineer and build your brand. It is important not to go too much into technical detail especially when there are non technical people in the audience who might not understand. I always begin my demos by telling a story. You can talk about the features and functionalities by talking about them in the context of a user story. The basic rules of good presentations are: keep it simple, rehearse the presentation, don’t memorize but use your notes very sparingly, dress for success, don’t go too fast, or too slow (Feierman, para. 11).
Feierman, A. The Art of Communicating Effectively. Retrieved November 30, 2014 from
Presentation for Client [Online Image]. Retrieved November 30, 2014 from
Ridenour, D. (March 11, 2014). Ensuring Mission Delivery for Government Projects [Online Image]. Retrieved November 30, 2014 from