Delivering a project and presenting to a multi-level audience



Figure 1: “Encoding communication” by Luis Javier Rodriguez Lopez


Figure 2: 01-1-to-many by Maxwell Hoffmann

A presenter deliver information to an audience in a way that the audience understand and make the information personal. In figure 1 The idea of coding a message and having all that information transferred to another and decoded while keeping the intended information intact. To do this a large diverse audience like what I am doing is this blog can be a challenging task. There is the need of the presenter to want to know their audience so they can tune their conversation to maximize the message they want to get across to the audience. In most situation any presenter is only going to know a small portion of the knowledge the audience is going to bring to a presentation. This small amount of information is what the presenter is going to need to feed off of to get the communication flowing. I find with a good presentation it can help move people to accept a delivery of a project, in the paper “Delivering the Project in Technical Consulting” by James L. Hawley and John Frauenhoffer, the authors note at how a good delivery of a project need a team that can do problem solving(p.61). Problem solving is the main function of the team in the project the client has a problem that the team will need to fix. In presenting the presenter has to solve the problem of getting information across the the audience.  In the paper “Using narratives and storytelling to communicate science with nonexpert audiences” by Michael F. Dahlstorm, notes at using a storytelling elements as a way to involve the audience the conversation. I can see myself using some strategy like using metaphors in describing some abstract ideas in computer science to people not well versed in computer science. The one problem I do have to look out for when abstracting information is making sure that information still comes back into one piece to my audience. The Figure 2 show the idea of one to many, which in a sense is what abstracting information, taking a single point and expanding/generalizing the idea.


Dahlstrom, M. F. (2014). Using narratives and storytelling to communicate science with nonexpert audiences. Proceedings Of The National Academy Of Sciences Of The United States Of America, 11113614-13620. doi:10.1073/pnas.1320645111

Hawley, J. L., & Frauenhoffer, J. (1996). Delivering the Project in Technical Consulting. Journal Of Architectural Engineering, 2(2), (pp. 55-62)

Hoffmann, M. (2013) 01-1-to-many [Image] Retrieved November 23, 2014 from

Lopez, L.J.R, Encoding communication [Image] Retrieved November 23, 2014 from



Handing off a project to a client; what are the risks and challenges?

Handing over control of a project seems like it might be scary to do when finishing a project for an outside client, as it means that as a developer your product better work as it is intended. This final stage problem, like ease of use and other end user issue have to be taken care of or as a developer you will find yourself with an unhappy customer. How can a developer go about taking care of handing a finished state project off to a client, I will tell you what I have done in handing over a project to a client.


Figure 1: The Raw flow of development. By Wesley Eversole

Currently I am handing over a website to a client and a lot of the work the team I am working with has been making sure the client can take care of their website with out needing to go in to the source code. In the paper”Key Factors for Developing a Successful E-commerce Website” by Osama Mohammed Ahmad Rababah and Fawaz Ahmad Masoud, the authors denote the three different areas which are the usability, conceptual reliability and representative reliability. The note that usability is the over all ease of maintaining, navigating adaptability and user friendliness the website offers. These were some of the core ideas we needed to give our website for our client to use. Figure 1 capture a raw essence of what development can be like. There is a loop that a developer must fill to satisfy their customer

When leaving a finished product with a client the developer should put them self in the head space of their client. The developer needs to make sure that they make using their product accessible. In the website I am building we decides on using word press as a launching point since work press has easy to navigate back end. For our client being able to work the website for themselves has been the key development choose we want to work in to the project. There is also the training we need to give our client since we know our client has limit skill in working a website that we have to plan for when handing over the project to them. In this case we have to train the client to be able to log in to the web site and then update pages they need to. The end hope of developing a website like this is to accomplish results like in “Agile for Dummies” written by Scott W. Ambler and Matthew Holitza, Where the IBM team was able increase the presences of the client from around 10 interactions to over 400 for a given project  (p. 58). A level like what is noted in “Agile for Dummies” is the end goal that the team I am apart of would like to accomplish make the client part of our design process. Doing that lets us teach the client so when we leave they will be able to manage their delivered product.


Ambler, S. & Holitza, M. (2012). Choosing an Agile Approach. In Agile for Dummies (IBM ed., p. 74). Hoboken: John Wiley & Sons.

Rababah, O. M. A., & Masoud, F. A. (2010). Key factors for developing a successful e-commerce website. Communications of the IBIMA, 2010, 1-9.

What five technical skills are employers seeking? What five soft skills put you on top?

In the past few week I have been doing some research into different career fields. I have been looking in fields like cloud development, computer networking and database management, just to name some fields I have looked into. When looking into each field I look at job requirements that the employers are looking for in new employees. There are two camps of skills every employer has under their skill requirements. The first is technical skills, the main reason the employer is looking to hire new employees. The second camp skills or what most employers call “Soft

Skills” are not written down as concrete visible like the technical skills but soft skills can help differentiate prospective employees that have the same technical skills. So lets take a deeper look into five technical skill Information system employers look for in new recruits and five soft skills that can help career hunters separate from other hunters.

In a study of the requirements from employers in the Information Systems field, written by Charles R. Woratschek and  Terri L. Lenox titled ”Information Systems Entry-Level Job Skills: A Survey Of Employers ”, the authors asked  and looked at past surveys to gather a view of the skill set employers are looking for in new Information System graduates. Woratschek and Lenox  findings were:

  • Programing languages, have the highest value to employers
  • Knowledge of Systems Development Life Cycles
  • Networking Concepts
  • Data Communication
  • Operating systems

Keep in mind that this research is coming from 2002 but the skill set employers in the field researched kept wide areas as any technology field will change quickly but these five skill areas as noted in the study give employees tools to adapt to the changes in the skills listed(p.4 ). When I look at these skills I see how even though back in 2002 cloud computing was still years away these skill would easily help people transition to a cloud platform like AWS or Google’s Cloud.

Woratschek and Lenox  also got a list of soft skills that employers desired all their employees to embody:

  • Professional Ethics
  • Motivation To Work
  • Ability to Learn
  • Attention To Details
  • Time Management

On their listing of soft skills they had listed 20 skill, I have the top 5 but like the technical skills I can see why these would be in the top 5(p.6). Each of the top five would help employees scouted with these skill evolve and keep up with the quickly changing technologies of the field. Changing with a field is not only good for the employee because they can have a job for many years but it also help a company from having to hire new employees with high demand skills. When companies have to look and hire new employees with high demand needs it can cost the company more money/time than having their current employees train up their technical skills.

the paper”Soft Skills and Technical Expertise of Effective Project Managers” written by Sharlett Gillard, talks about the different technical and soft skills a project manager need to be successful according to others research.  Skill like communication were some of the top soft skill required for a project manager to be deemed successful(pp.724-725). In my current project, when I was a sprint leader for the project, I found how important it is to have clear communication. I attempted to make clear communication channels for which the team could communicate like utilizing a Facebook groups posting system. The use of a Facebook groups chat I found useful for centralization of communication which led to a lowering of issues of missing a person in a group email message. Having a clear communication channel did helped reduce possible issues of having a group member misinterpret or miss what I was trying to concave– to the team. The reduction in errors reduced any error extra error fixing time that would have had to been done if that communication was not there.

Getting down technical skills will help anyone pick a field to work in but having the wanted soft skill will help people stick in the job fields they want.



Gillard, S. (2009). Soft skills and technical expertise of effective project managers. Issues in Informing Science and Information Technology, 6(2009), 723-729.

Woratschek, C. R., & Lenox, T. L. (2002, October). Information systems entry-level job skills: a survey of employers. In Proceedings of the Information Systems Educators Conference, San Antonio TX (Vol. 19).

A Flight Into Cloud Computing

old cloud

My Old View of “The Cloud”

Last week I had the privilege to attend the IT Cloud Computing Conference (IC3). Before I went to the conference I had a vague idea of what the cloud was. I thought when people referenced the cloud they were referencing data or hosting data on servers owned by other companies. Services like iCloud and Google Drive are just some of these cloud storage services running on top of a cloud infrastructure and are just a small subset of the greater cloud computing environment. What I now understand as the “cloud”, is that it can be broken into two grouping of infrastructure: publicly run, owned and use by other entities (Google, Amazon), or privately owned, used and maintained by the ones owning the cloud system. The public sector of cloud computing allows developers to set up virtual system with flexible computing power as a service instead of a physical asset that is owned and must be maintained. The cloud computing market as it is now is trying to develop computing technology as service. The paper “Scientific Cloud Computing: Early Definition and Experience” written by Lizhe Wang and Gregor von Laszewski, observed that cloud computing should be indistinguishable to the user from a hardware environment, accessing the cloud should be location agnostic along with not needing massive local system requirements. In the end the people accessing cloud services should not need to know how the cloud works in order to access anything utilizing cloud computing. The authors lend ideas about how developers working on cloud platforms have computer systems that they no longer need management teams working on a computer system. On cloud systems individual developers can manage large computer system with ease, allowing them to focuses on creating rather than management of a large hardware infrastructure. The article “Business Models in the Service World” written by Christof Weinhardt, Arun Anandasivam, Benjamin Blau, and Jochen Stößer,

High level view of public and private cloud

High level view of public and private cloud

I  find the article digs more in to the business cost of side cloud computing. The authors for this article found the payment plan “pay per use” to be the most cloud computing platforms leaned towards that payment style as makes computing more of a service industry(pp. 40-41). As I am currently a student in college the prospects of having the ability to set up my own web server without having to own hardware running on a cloud service. In certain cloud ecosystems I can pay for what I use, allowing me to experiment on different development platforms, without the heavy cost of failure associated with owning and maintaining my own hardware. When computing is a service if I need more computing power I can simply buy more power and in seconds I have that power which I find beats out physical upgrading which takes time. In closing I just wanted to get out there a very high overview of cloud computing as a platform. I plan to explore this topic in greater detail as way to help myself and other understand this field.


Wang, L., & Von Laszewski, G. (2008). Scientific Cloud Computing: Early Definition and Experience. 1-18. Retrieved November 2, 2014, from

Weinhardt, C., Anandasivam, A., Blau, B., & Stößer, J. (2009). Business Models in the Service World. IT Pro, 36-41. Retrieved November 3, 2014, from

LinkedIn and How to go About Management of Social Media Profiles

Global Membership_August 5 2014

Figure 1. Global Membership_August 5 2014 from LinkedIn

Updates of that quaint Italian restaurant, some friends have just started talking about to the cultural revolution in Egypt and even branding one’s self for prospective jobs. Increasingly the idea of branding one’s self online is becoming the standard way of what some people “call job hunting”. One way I brand myself is to be apart of a website like LinkedIn. One reason to use a site like LinkedIn is the popularity of such sites (I.e. figure 1). LinkedIn has a massive amount of accounts from all over the world, giving someone like me a world stage to broadcast the business of me from. With broad casting to suck a large amount of people, it is important not to send out messages that are meaning less, other wise someone’s messages will get lost out in the sea of people inhabiting places like LinkedIn. I like these simple rules on how to talk on social media from “The B2B marketer’s essential guide” from Coast Digital (Bond, p. 9).

  1. Don’t treat social media as a broadcast medium – you can’t strike up conversations if you’re shouting.
  2. Don’t expect instant returns – it takes time to build relationships online too.
  3. Analyze the mutual benefits in all your offline relationships – it’ll help you use social media to create similar benefits online.
  4. Talk to the right people – are you building relationships with people who can help your long-term business goals?
  5. Map out your landscape – who do you know? Where do they hang out online? Who are your advocates? Are your competitor already in this space?
Figure 2. by Wesley Eversole

Figure 2. A Facebook group by Wesley Eversole

The first premise made by Coast Digital I interpret at make social media in to an advertising platform for yourself. This can help stop the shouting in to the void of a social network that some people tend to use social media for. The second statement can go for anything in life, I would not expect job offers to be popping up seconds after I update my LinkedIn profile, but if keep my profile reflecting my skills / career plan, then it will help me obtain a career. In the third statement the idea for it that I apply to LinkedIn is that if like a group of people with common interests find a group in LinkedIn that one can contribute to conversationally. The fourth statement I feel is just more of the same from the third statement, have connections to people who will add to one’s worth in the eyes of an employer. The last statement is the most if applied to structuring connections on LinkedIn. An example of what social networks look like is figure 2, this web is a web graph of a group I belong to on Facebook. One can see all the connections or lack of connections to each node (one node is one person). For example if everyone in the web graph was attempting to get hired by the largest node, the largest node would have most contact with people directly connected with them. If the largest node hires one of its direct connections it might look in to who is connected to that person. Now on the other side of this hypothetical hiring event, knowing who is connected to the person hireling may help a person find out what skills the employer might be looking for in its prospective employees. The way skill information is shared in LinkedIn is by a tagging system. A paper Yi-Ching Huang, Chia-Chuan Hung and Jane Yung-jen Hsu titled “You Are What You Tag” bring up the how much a person can learn from how people tag internet bookmarks. They mentioned that a tag can have different meaning to different people (p.2). In the realm of skill tags in LinkedIn I would suggest staying with tags that one can prove that they do have the noted skills.

Following these suggested rules may not be the sole reason any one will be hired from LinkedIn but it can help make someone’s interaction with professionals stand out. When it comes to a job market being identifiable will go along far in helping any job hunt.


Bond, D. (n.d.). Demystifying social media (p. 27). Coast Digital.

LinkedIn (2014) LinkedIn Global Membership August 5, 2014 Retrieved October 28, 2014 from

Huang, Y., Hung, C., & Yung-jen Hsu, J. (2008). You Are What You Tag. 1-6. Retrieved October 18, 2014, from

Agile tasks lists, what does “done” mean in Agile?

In the world of development having a plan is important to help focus ideas. Having a plan can help direct work flows and generally make project with a lot of people easier to organize. If the plan is too rigid, that once a part of the project is finished that part is ready to ship it can hinder the projects work flow. In development ecosystems like agile plans or task list help guide teams towards a finished product. At the end of each sprint there is a retrospective, which in the team will put down a completed or “done” task. Tasks marked as “done” maybe finished but are not exempt from change.

What is Scrum? by Henrik Kniberg

What is Scrum? by Henrik Kniberg

The image from Henrik Kniberg slide show about agile development I think embodies the main idea of what an agile task list should be. It’s simple enough that it can change, without being to simple that nothing can be gained from it. It is also not so structured that nothing can ever change in it. The book “Agile for Dummies” by Scott W. Ambler and Matthew Holitza looks at the what agile developers can gain by implementing a task list. The authors look at things like “Tracking Velocity”, which follows the “Done Tasks” or the deliverable work. Handling Deliverable work allows a team to deal with small part of the over all projects and allows a set task to have a well-defined goal without having a strict overbearing plan like in waterfall(pp. 20-24). Since fluid nature of agile tasks allows the task to change throughout development, there has been research into this aspect of agile. The paper “Requirement Gathering and Tracking Process for Distributed Agile based Development” by Rehan Akbar, Muhammad Haris and Majid Naeem, explored the ideas of agile’s ability to allow changeable tasks design in large agile development groups, when agile uses simple documentation. The papers finding on the agile development documentation, was that simple design allowed teams to quickly shift design goals. The shifting in-goal allowed the management team, they were following, to better direct the other teams to finish the project(pp. 432-434). The shifting in the agile can be the reassessment of task that a team thought was “done”. Moving a task from “done” to working goes back to Knibergs image, letting us know that having something be strict like a “done” task be able to become a “to-do” task breaks from development methods like waterfall. There is also a downside to the reevaluation of “done” tasks that everyone should know about. Moving task from a “done” state to a “being worked” on state can make a project drag on which no teams wants. A team when deciding on bring back a done task might want to thing about the current task list and re plan when to rework a “done” task.


Akbar, R., Haris, M., & Naeem, M. (2008). Requirement Gathering and Tracking Process for Distributed Agile based Development. 8th WSEAS International Conference on APPLIED INFORMATICS AND COMMUNICATIONS, 429-436. Retrieved October 12, 2014, from

Ambler, S., & Holitza, M. (2012). Choosing an Agile Approach. In Agile for Dummies (IBM ed., p. 74). Hoboken: John Wiley & Sons.

Kniberg, H. (2014) What is Scrum? [Diagram] Retrieved October 12, 2014 from

What is an Agile Sprint Retrospective?

One of the most useful tools in the agile development arsenal is the process of a sprint retrospective.
The simple idea of a sprint retrospective is to review the product backlog and do any changes the team need to in order to keep the project on track. The sprint retrospective according to the authors of “Agile for Dummies” Scott W. Ambler and Matthew Holitza, they see a retrospective as a team progress check up. A check up where the team can meet up by themselves or with useful stakeholders to go over
any issues in the latest sprint and figure a game plan to tackle the issues discovered in the upcoming sprint (p. 32). The key thing to note is that the sprint retrospective is a learning tool and aids in product flow.

Using a sprint retrospective as a learning tool for any agile team is an imperative resource that teams should not neglect. The sprint retrospective is not something that a development team should be scared of. The team should be looking froward towards the retrospective during the sprint since this allows the whole team to reflect on the past sprint. It is a good place for a team to be in knowing what they still have to do, what they need to change product flow wise and bring up personal issues a team member might be having with a project. A problem with bringing up personal problems, noted in “Decision Making in Agile Development: A Focus Group Study of Decisions & Obstacles” by Meghann Drury, Kieran Conboy and Ken Powers, is that they found people can use a retrospective as a way to vent about the project. Drury, Conboy and Powers in their interviews look at some team member found the meeting to be chaotic.

Dev8D Retrospective by Steve Coppin

Dev8D Retrospective by Steve Coppin

These members felt the retrospective would end up not directing the team down the path of completing the project (pp. 44-45). Venting problems with a project maybe use full only if those issues can help move the project forward, otherwise it can affect the team from tackling design issues. To drive this point home by the end of a given retrospective meeting there should be an idea of how to move the project forward. The diagram ”Dev8D Retrospective” from Steve Coppin, shows one lay out of how to represent information brought about in a retrospective. The diagram brings up four areas of different comments.

  • What did we do well
  • What didn’t go so well
  • What could we do differently
  • what still puzzles us

A team able to bring up issues in the project in those four areas can then start to develop ways of correcting problem and complementing good deeds the team was able to accomplish.

A good retrospective does a lot to move the project along and as not early should not be feared by the team. Any team will want to embrace all the negative and positive information coming from a retrospective as long as it can help progress the project.


Ambler, S., & Holitza, M. (2012). Choosing an Agile Approach. In Agile for Dummies (IBM ed., p. 74). Hoboken: John Wiley & Sons.
Coppin, S. (2010) Dev8D Retrospective [Diagram] Retrieved September 28, 2014 from
Drury, M., Conboy, K., & Power, K. (2011). Decision Making in Agile Development: A Focus Group Study of Decisions & Obstacles. 2011 Agile Conference, 39-47. Retrieved September 28, 2014, from IEEE Xplore. Web Address.


Agile Manifesto

12 principles of Agile